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Abstract 

This  thesis  demonstrates  and  illustrates  a  way  of  developing  reusable  graphics  software 
components  in  Ada  associated  with  a  C++/C  library.  The  work  was  carried  out  using  object- 
oriented  software  development  techniques  that  were  used  to  analyze,  design  and  implement  a 
partial  flight  simulator.  The  objective  of  this  thesis  was  to  present  a  way  of  building  reusable 
software  components  with  Ada  in  a  graphics  application  environment. 

An  object-oriented  approach  was  taken  in  the  development  of  a  set  of  reusable  graphics 
software  components  for  a  flight  simulator  domain.  A  selection  of  a  set  of  reusable  software 
components  came  from  domain  analysis.  These  components  were  analyzed  in  detail,  ‘hen 
redesigned  to  demonstrate  and  illustrate  the  thesis  objective.  Examples  from  design  and 
implementation  demonstrate  how  Ada  83  was  applied  in  building  reusable  graphics  software 
components  associated  with  C-H-  routines,  the  limitation^  of  Ada  83,  and  how  Ada9X 
addresses  these  limitations. 
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I.  Introduction 

l.I  Background 

The  problems  with  software  today  are  typically  associated  with  what  some  people  call 
the  “software  crisis”.  “Over  the  past  ten  years,  the  software  crisis  has  cost  the  Department 
of  Defense  alone  tens  of  billions  of  dollars”  (42:2).  As  software  development  and  maintenance 
costs  have  continued  to  rise  at  ever  increasing  rates,  the  use  of  standards  as  a  solution  to  the 
problem  has  bten  suggested.  Standardization  is  far  more  important  in  the  drive  toward  reuse 
than  special  mechanisms  particular  languages  may  offer  (14).  Ada  has  been  established  as  the 
single,  standardized  programming  language  within  the  U.S.  Department  of  Defense  (DoD). 
The  aim  was  to  replace  the  vast  number  of  languages  and  ad  hoc  techniques  previously 
in  use  with  a  standard  programming  paradigm  to  promote  maintainability,  reusability,  and 
portability.  Program  portability  and  reuse  of  software  components  are  a  major  concern  of 
the  DoD  as  well  eis  the  software  industry  since  both  use  a  wide  vailety  of  hardware  platforms. 
However,  a  problem  introduced  by  the  newness  of  Ada  is  a  lack  of  potential  experience  in 
several  key  areas.  For  example,  the  effective  use  of  Ada  in  solving  graphics  problems  with 
DoD  requirements. 

A  problem  of  this  type  is  evident  in  the  flight  simulator  software  that  was  partially 
developed  by  several  Air  Force  Institute  of  Technology  (AFIT)  students  (15,  26,  37).  The 
program  was  written  in  C++  rather  than  Ada,  and  it  exhibits  many  of  the  engineering 
difficulties  that  prompted  the  development  of  Ada.  'T'his  thesis  will  investigate  the  use  of 
Ada  to  replace  C++/C  in  a  graphics  application. 
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A  problem  with  the  use  of  Ada  is  a  lack  of  potential  experience  in  several  key  areas 
such  as  the  effective  use  of  Ada  in  solving  graphics  problems  with  DoD  requirements. 

1.3  Hypothesis 

The  hypothesis  of  this  thesis  was  that  the  advanced  features  of  the  Ada  programming 
language  could  be  successfully  interfaced  with  the  advanced  graphics  libraries  of  a  Silicon 
Graphics  System  and  existing  0++  code. 

1.4  Research  Objective 

The  overall  goal  of  this  research  was  to  investigate  and  to  demonstrate  Ada’s  applica¬ 
bility  as  an  implementation  language  for  a  reusable  graphical  software  component  using  an 
object-oriented  pproach.  During  the  course  of  the  investigation,  two  of  the  following  Ada 
features  were  examined: 

•  What  problems  exist  with  Ada  83  in  building  reusable  graphics  software  components 
using  an  object-oriented  approach,  and  how  these  problems  are  addressed  in  Ada  9X, 

•  How  to  connect  Ada  programs  to  existing  C-f-f  code. 

1.5  Scope 

The  design  and  implementation  of  parts  of  a  flight  simulator  will  serve  as  the  founda¬ 
tion  for  the  investigation  of  Ada’s  applicability  as  an  implementation  language  for  graphics 
programs. 

1.6  Assumptions 

1.6.1  Hardwaix.  A  flight  simulator  written  in  C-f-|-  was  executed  on  a  Silicon 
Graphics  IRIS  (SGI),  so  access  to  an  SGI  was  necessary. 
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1.6.2  Software.  VVe  had  access  to  the  following  sources  of  software: 

•  Ada:  The  Verdix  Ada  Development  System  (VADS)  was  used.  VADS  provides  users 
with  a  complete  software  environment  for  developing  Ada  language  applications.  VADS 
provides  users  with  useful  libraries  for  interfacing  to  the  Silicon  Graphics  Graphics 
Library,  Font  Manager  Library,  operating  system  calls,  etc. 

•  The  C++  programming  language:  The  AT/T  C++  translator  release  2.0  was  used. 

•  Unix  Standard  Library:  We  were  working  within  the  Unix  operating  system.  We 
therefore  were  able  to  use  Unix  standard  system  calls  and  “C”  software  libraries. 

•  Previous  Thesis  Efforts:  The  work  done  by  Captain  Simpson  (37)  for  controlling  the 
input  devices  was  reused  in  this  thesis. 

1.7  Approach  I  Methodology 

An  incremental  approach  was  taken  in  the  development  of  this  thesis  project.  First, 
the  domain  of  the  flight  simulator  was  analyzed  and  a  set  of  components  was  selected. 
Then  the  existing  C++/C  code  and  the  object-oriented  model  were  analyzed  for  design 
of  reusable  software  components.  As  a  part  of  this,  Ada  bindings  to  C++  and  C  were 
analyzed.  Then  alternatives  for  obtaining  well-engineered  reusable  software  components 
were  examined.  Finally,  the  alternatives  were  analyzed,  and  the  most  effective  one  was 
chosen  and  implemented. 

1.8  Materials  and  Equipments 

The  following  materials  and  equipment  were  used  in  this  research. 

•  Target  Machine  :  Silicon  Graphics  IRIS  4D  Series 

•  Joystick  :  Microstick  Joystick  from  CH  Products 


1.9  Summary 

As  software  development  and  maintenance  costs  have  continued  to  rise  at  ever  increas¬ 
ing  rates,  the  use  of  standards  as  a  solution  to  the  problem  has  been  suggested.  Ada  has 
been  established  as  the  single,  standardized  programming  language  within  the  U.S.  DoD  to 
replace  the  vast  number  of  languages  and  ad  hoc  techniques  previously  in  use  to  promote 
reusability,  maintainability,  and  portability.  This  thesis  examines  previous  thesis  work  on 
flight  simulator  software  implemented  in  C-b-f,  and  then  builds  on  this  work  using  Ada. 

The  objective  of  this  thesis  is  to  demonstrate  and  illustrate  the  feasibility  of  building 
well-engineered  reusable  graphics  software  components  in  Ada. 

1.10  Thesis  Overview 

This  document  contains  five  chapters.  Chapter  2  is  a  literature  review  of  object- 
oriented  technology,  software  reuse,  and  the  contrasts  of  Ada  and  C-f-f/C.  Chapter  3  out¬ 
lines  the  process  used  to  examine  the  problem  as  well  as  the  design  of  reusable  software 
components.  Chapter  4  describes  detailed  design  and  implerhentation  strategies  in  building 
a  well-engineered  reusable  set  of  components  in  conjunction  with  C-I-+  routines  in  a  class 
library.  Chapter  5  includes  a  summary  and  conclusions. 
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11.  Literature  Review 


2.1  Introduction 

The  purpose  of  this  chapter  is  to  aid  in  the  understanding  of  the  discussion  contained 
in  the  following  chapters.  This  chapter  begins  with  a  description  of  the  need  for  object- 
oriented  techniques,  followed  by  concepts  of  the  object-oriented  paradigm  with  the  basic 
analysis  and  design  concepts.  This  description  is  followed  by  a  description  of  software  reuse, 
especially  focusing  on  reuse  of  code  components.  The  features  of  Ada  and  C++/C  are  then 
considered  for  similarities  and  contrasts.  This  is  followed  by  a  description  of  interfacing  Ada 
with  C++/C  and  a  description  of  the  MICROSTICK  device  used  in  this  study. 

2.2  The  Object-Oriented  Paradigm 

2.2.1  The  Need  for  Object-Oriented  Techniques.  Among  software  engineers  the 
software  crisis  is  a  well  known  fact  (8,  29).  “The  essence  of  the  software  crisis  is  simply  that 
it  is  much  more  difficult  to  build  software  than  our  intuition  tells  us  it  should  be”  (8:7).  In 
general,  the  software  crisis  is  characterized  by  many  problems,  while  managers’  responses 
for  software  development  concentrate  on  the  “bottom-line”  issues  such  as:  1)  inaccurate 
schedule  and  cost  estimates;  2)  the  lack  of  “productivity”  from  software  engineers;  and  3) 
the  lack  of  software  quality  (29).  The  major  cause  of  the  software  crisis  is  the  complexity  of 
software  and  software  itself  (7).  The  previous  situation  highlighted  the  need  for  developing 
and  maintaining  large  complex  software  systems  in  a  competitive  and  dynamic  environment, 
and  it  has  driven  interest  in  new  approaches  to  software  design  and  development.  The  goals 
{modifiability,  efficiency,  reliability,  understandability)  and  principles  [modularity,  abstrac¬ 
tion,  localization,  information  hiding,  uniformity,  completeness,  confirmability)  of  software 
engineering  as  stated  by  Goodenough,  Ross,  and  Irvine  (16)  and  Booch  (8),  provide  the 
foundation  upon  which  software  will  be  designed  in  the  future.  “Object-oriented  design, 
object-oriented  programming,  and  object-based  programming  are  methods  that  support  the 
goals  and  principles  of  software  engineering”  (31:76). 
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2.2.2  Object-Oriented  (00)  Paradigm.  Although  many  discussions  have  taken 
place,  little  consensus  has  been  reached  as  to  exactly  what  is  meant  by  “object  orienta¬ 
tion'’,  even  among  leaders  like  Booch  (7),  Meyer  (24),  and  Stroustrup  (38).  Henderson 
and  Eklwards  (17:146)  define  the  object-oriented  paradigm  as  follows:  “The  object-oriented 
(00)  paradigm,  at  its  simplest,  takes  the  same  components  of  a  software  system:  data  and 
procedures,  but  de-emphasizes  the  procedures,  stressing  instead  the  encapsulation  of  data 
and  procedural  features  together,  exemplified  by  the  clear  and  concise  specification  of  the 
module  interface”.  The  paradigm  sprang  from  language,  has  matured  into  design,  and  has 
recently  moved  into  analysis.  Several  general  concepts  that  are  strongly  related  with  the 
00  paradigm  will  be  discussed  in  this  chapter:  objects,  classes,  abstraction,  inheritance,  en¬ 
capsulation,  polymorphism,  and  dynamic  binding.  Although  these  concepts  are  basic  to  the 
object-oriented  paradigm,  the  various  object-oriented  communities  often  associate  different 
specifics  with  each  concept.  This  section  focuses  on  those  concepts. 

2.2.2. 1  Objects.  Booch  (7)  defines  an  object  as  follows: 

An  object  is  a  tangible  or  visible  entity  that  exhibits  some  v/ell-defined  behavior. 

It  has  state,  behavior,  and  a  unique  identity;  the  state  of  an  object  encom¬ 
passes  all  of  the  properties  of  the  object  plus  the  current  values  of  each  of  these 
properties,  the  behavior  is  how  an  object  acts  and  reacts,  in  terms  of  its  state 
changes  and  message  pcissing,  and  identity  is  that  property  of  an  object  which 
distinguishes  it  from  all  other  objects. 

Objects,  well-defined  and  limited,  may  contain  both  data  structures  and  actions  to  be  per¬ 
formed  on  the  structures.  The  bjisic  principles  behind  objects  are:  1)  abstraction,  2)  encap¬ 
sulation,  3)  modularity,  4)  hierarchy,  and  5)  polymorphism  (27). 

1)  Abstraction  is  the  process  of  defining  an  object  in  just  the  right  amount  of  detail 
for  the  situation.  The  goal  is  to  use  just  enough  detail  to  differentiate  a  new  object  from 
other  objects  at  the  same  level.  The  easiest  way  to  do  this  is  to  portray  the  operations  the 
object  can  perform  before  worrying  about  operations  within  the  object. 
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2)  Encapsulation  involves  hiding  information  about  an  object  from  the  user.  It  hides 
the  details  of  the  implementation  because  the  user  doesn’t  care  how  operations  are  imple¬ 
mented,  only  how  to  use  them. 

3)  Modularity  follows  the  principle  of  divide  and  conquer:  Divide  the  problem  into 
pieces  and  keep  each  piece  of  the  solution  in  independent  modules.  The  object  is  perfect  for 
modularity  because  it  holds  the  data  structures  and  operations  for  each  part  of  the  solution. 
The  module  is  also  loosely  coupled  because  it  is  not  tied  closely  to  other  parts  of  the  program. 

4)  Hierarchy  means  that  objects  are  abstracted  in  terms  of  the  problem  to  be  solved, 
then  described  in  more  specific  terms,  with  the  objects  adding  characteristics  or  inheriting 
others  from  existing  Objects. 

5)  Polymorphism  refers  to  the  ability  of  an  object  to  assume  multiple  roles  and  shapes. 
For  instance,  ’’overloading”  is  a  fancy  term  for  the  simple  practice  of  using  an  operator  for 
more  than  one  type  of  data. 

8.2. 2. 2  Classes.  A  class  is  a  set  of  objects  that  share  a  common  structure 
and  common  behavior.  Korson  (21:42)  defined  a  class  as  follows: 

Ideally,  a  class  is  ?.n  implementation  of  an  abstract  data  type.  This  means  that  the 
implementation  details  of  the  class  are  private  to  the  class.  The  public  interface 
of  such  a  class  is  composed  of  two  kinds  of  class  methods.  The  first  kind  consists 
of  functions  that  return  meaningful  abstractions  about  an  instance’s  state.  The 
other  kinds  of  methods  are  transformation  procedures  used  to  move  an  instance 
from  one  valid  state  to  another. 

By  grouping  objects  into  classes,  a  problem  can  be  abstracted.  Class  is  the  language  construct 
most  commonly  used  to  define  abstract  data  types  in  object-oriented  programming  languages. 

2.2.2. 3  Abstraction.  Abstraction  is  the  fundamental  concept  of  object  ori¬ 
entation.  “An  abstraction  denotes  the  essential  characteristics  of  an  object  that  distinguish 
it  from  all  other  kinds  of  objects  and  thus  provides  crisply  defined  conceptual  boundaries, 
relative  to  the  perspective  of  the  viewer”  (7:39).  Abstraction  is  one  of  the  fundamental  ways 
that  we  humans  cope  with  complexity.  Abstraction  encourages  programmers  and  users  to 


think  about  complex  applications  in  abstract  terms.  “The  goal  of  abstraction  is  to  isolate 
those  aspects  that  are  important  for  some  purpose  and  suppress  those  aspects  that  are  unim¬ 
portant”  (32:16).  There  are  two  methods  of  abstraction:  abstraction  by  specification  and 
abstraction  by  parameterization  (21). 

Abstraction  by  specification  abstracts  the  specification  of  an  entity  from  its  implemen¬ 
tation.  This  type  of  abstraction  is  supported  by  virtually  every  object-oriented  language. 
The  public  interface  of  a  class  constitutes  the  specification  of  that  class.  The  interface 
specifies  the  legitimate  operators  of  the  data  contained  in  instances  of  the  class. 

Abstraction  by  parameterization  abstracts  the  type  of  data  to  be  manipulated  from 
the  specification  of  how  it  is  to  be  manipulated.  This  type  of  abstraction  is  supported  by 
most  object-oriented  languages  at  the  operator  level,  but  by  only  a  few  languages  at  the 
class  level. 

2.2.2.4  Inheritance.  Inheritance  is  a  relation  between  classes.  “Inheritance  is 
the  sharing  of  attributes  and  operations  among  classes  based  on  a  hierarchical  relationship” 
(32:3).  It  is  not  provided  by  conventional  languages.  “Inheritance  is  a  way  of  defining  some 
useful  construct  in  a  central  place  and  then  automatically  broadcasting  that  construct  to 
all  the  places  where  it  could  help.  New  functionality  is  no  more  developed  by  coding  each 
line  from  scratch,  but  by  inheriting  some  useful  class  and  describing  only  how  the  new  one 
differs”  (13:12).  Inheritance  not  only  supports  reuse  across  systems,  but  it  directly  facilitates 
extensibility  within  a  given  system. 

2. 2. 2. 5  Encapsulation.  Encapsulation  is  the  way  of  building  of  methods 
and  data  together  within  an  object  so  that  access  to  data  is  permitted  only  through  the 
object’s  own  methods  (2:35).  “Abstraction  and  encapsulation  are  complementary  concepts: 
abstraction  focuses  upon  the  outside  view  of  an  object  and  encapsulation  -  also  known  as 
information  hiding  -  prevents  clients  from  seeing  its  inside  view,  where  the  behavior  of  the 
abstraction  is  implemented”  (7:45). 
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2. 2. 2. 6  Polymorphism.  As  Cardell  (9)  points  out  there  are  many  kinds  of 
polymorphism,  but  in  general,  polymorphism  means  the  ability  to  take  more  than  one  form. 
The  same  operation  may  apply  to  many  different  classes,  that  is,  the  same  operation  takes 
on  different  forms  in  different  classes.  Because  of  this  ability  to  refer  to  more  than  one  class 
of  object,  a  polymorphic  reference  has  both  a  dynamic  and  a  static  type  associated  with  it 
(21). 

The  dynamic  type  of  a  polymorphic  reference  may  change  from  instant  to  instant 
during  the  program  execution.  In  strongly  typed  object-oriented  environments,  the  run-time 
system  keeps  all  polymorphic  references  automatically  tagged  with  their  dynamic  type. 

The  static  type  is  determined  from  the  declaration  of  the  entity  in  the  program  text. 
It  is  known  at  compile  time  and  determines  the  set  of  valid  types  that  the  object  can  accept 
at  run-time. 


2. 2. 2. 7  Dynamic  Binding.  The  binding  discussed  in  this  chapter  is  the  bind¬ 
ing  of  a  procedure  call  to  the  code  to  be  executed  in  response  to  the  call.  Dynamic  binding 
means  that  binding  is  done  later  than  compile-time,  generally  while  the  program  is  running. 
“Dynamic  binding  is  needed  in  loosely  coupled  collections  where  the  customer’s  code  cannot 
predict  the  type  of  data  to  be  operated  on  until  the  code  is  being  run”  (13:14).  Dynamic 
binding  is  intrinsic  to  the  very  essence  of  a  loosely  coupled  collection.  “In  the  object-oriented 
world,  dynamic  binding  is  associated  with  polymorphism  and  inheritance  in  that  a  proce¬ 
dure  call  associated  with  a  polymorphic  reference  may  depend  on  the  dynamic  type  of  that 
reference”  (21:46). 

2.2. 2. 8  Terminology.  This  discussion  introduces  key  concepts  and  defini¬ 
tions  from  the  00  domain.  Like  any  emerging  technologies,  00  has  many  proponents  with 
differing  opinions.  Since  object-oriented  methodologies  are  in  their  early  stage,  like  the  vari¬ 
ous  object-oriented  programming  languages,  terminology  for  the  object-oriented  mechanisms 
differs  among  methodologies  (2:189). 
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2.2.3  Object-Oriented  System  Life  Cycle.  “At  the  most  general  level,  three 
phases  to  the  life  cycle  are  generally  agreed  upon:  1)  analysis,  2)  design  and  3)  construc¬ 
tion/implementation”  (17:143).  Like  a  general  software  development  life  cycle,  an  object- 
oriented  development  life  cycle  also  has  anal)'sis,  design,  and  implementation  phases.  Prob¬ 
lems  with  traditional  development  using  the  classical  life  cycle  include  no  iteration,  no  em- 
phtisis  on  reuse,  and  no  unifying  model  to  integrate  the  phases  (21).  In  contrast  to  the 
common  structured  systems  analysis  and  design  based  largely  on  top-down  functional  de¬ 
composition,  object-oriented  analysis  and  design  has  many  attributes  of  both  top-down  and, 
perhaps  predominantly,  bottom-up  design.  Since  one  of  the  aims  of  an  00  implementation 
is  the  development  of  generic  classes  for  storage  in  libraries,  an  approach  which  considers 
both  top-down  analysis  and  bottOm-up  design  simultaneously  is  likely  to  lead  to  the  most 
robust  software  systems  (17:146).  The  object-oriented  analysis  and  the  object-oriented  de¬ 
sign  phases  work  more  closely  together  because  of  the  commonality  of  the  object  model. 
In  one  phase,  the  analyst  identifies  problem  domain  objects  while  in  the  next  phase,  the 
designer  specifies  additional  objects  necessary  for  a  specific  computer-based  solution.  The 
design  process  is  repeated  for  these  implementation-level  objects. 

2.2.3. 1  Basic  Analysis  Concepts.  “Object-Oriented  Analysis  (OOA)  is  a 
method  of  analysis  that  examines  requirements  from  the  perspective  of  the  classes  and  objects 
found  in  the  vocabulary  of  the  problem  domain”  (7:37).  It  is  concerned  with  constructing 
a  precise,  concise,  understandable,  and  correct  model  of  the  real  world.  “The  analysis 
model  serves  several  purposew.  It  clarifies  the  requirements,  it  provides  a  basis  for  agreement 
between  the  software  requestor  and  the  software  developer,  and  it  becomes  the  framework 
for  later  design  and  implementation”  (32:148).  There  are  several  OOA  approaches  (7,  10,  17, 
32,  35)  each  with  their  own  techniques.  These  methods  can  be  summarized  by  the  following 
activities,  which  may  overlap. 

•  Identify  the  classes/objects  of  problem  space 

•  Identify  the  relationship  between  classes 
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•  Identify  the  attributes  and  methods  of  each  class/object 

•  Specify  the  inter-object  communication. 

2.2.3.2  Basic  Design  Concepts.  This  section  describes  the  fundamentals  of 
the  object-oriented  design  phase  of  the  object-oriented  software  life  cycle.  The  different  point 
of  view  between  the  procedural  design  paradigm  (top-down  functional  decomposition)  and 
object-oriented  design  is  that  the  procedural  paradigm  takes  a  task-oriented  point  of  view, 
while  the  object-oriented  design  paradigm  takes  a  modeling  point  of  view  (21).  Booch  defines 
object-oriented  design  (OOD)  as  follows.  “Object  oriented  design  is  a  method  of  design 
encompassing  the  process  of  object-oriented  decomposition  and  a  notation  for  depicting 
both  logical  and  physical  as  well  as  static  and  dynamic  models  of  the  system  under  design” 
(7:37).  The  application  design  process  begins  at  a  top  level  and  proceeds  through  class 
identification  to  a  low  level  and  then  moves  upward  as  low-level  classes  are  designed  based 
on  lower-level  definitions.  The  object-oriented  paradigm  provides  support  for  good  design: 
1)  modularity,  2)  information  hiding,  3)  weak  coupling,  4)  strong  cohesion,  5)  abstraction, 
6)  extensibility,  and  7)  integration  (21).  There  are  many  sources  of  advice  on  what  makes  a 
good  design  (10,  32). 

2. 2. 3. 3  Notation.  To  do  analysis  and  design,  v/e  need  a  way  to  picture  the 
things  we  want  to  build,  a  notation  for  modeling  the  structure  of  object-oriented  software. 
“Any  graphical  representation  of  the  object-oriented  (Version  of  the  overall  software  devel¬ 
opment  life  cycle  must  take  into  account  the  high  decree  of  overlap  and  implicit  iteration” 

(17:151)  Various  notations  have  been  introduced  by  various  authors  (7,  10,  24,  32). 

1 

I 

2.2.4  Benefits  and  Drawbacks  of  the  Object-Oriented  Approach.  Like  a  classical 

approach,  the  object-oriented  approach  also  has  its  benefits  and  drawbacks. 

1 

I 

I 

2.2.4. 1  Benefits.  The  object-oriented  paradigm  offers  the  following  benefits: 
1)  a  way  to  manage  complex  software,  2)  a  “seamless”  way  to  perform  analysis,  design 
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and  implementation,  3)  reusability,  4)  maintainability  and  5)  extensibility  (37:2-28).  Bocch 
noted  the  following  benefits  by  applying  object-oriented  design  (7). 

•  Exploits  the  expressive  power  of  all  object-based  and  object-oriented  programming 

languages 

•  Encourages  the  reuse  of  software  components 

•  Leads  to  systems  that  are  more  resilient  to  change 

•  Reduces  development  risk 

•  Appeals  to  the  working  of  human  cognition 

2. 2. 4-2  Drawbacks.  Although  the  00  approach  has  valuable  benefits,  it  also 
has  some  drawbacks  that  must  be  considered.  There  two  acknowledged  drawbacks  to  using 
the  object-oriented  approach:  1)  performance  considerations,  2)  start-up  cost  (7:216). 

Early  object-oriented  programming  languages  such  as  Smalltalk  were  interpreted  and 
thus  inefficient  compared  to  a  conventional  programming  language  (32:10).  Subsequently, 
performance  sensitive  systems  could  not  be  designed  and  coded  in  object-oriented  languages. 
Today,  with  the  introduction  of  new  languages,  OOD  systems  have  improved  in  performance. 
Initial  investments  in  education,  tool  support,  reorganization,  and  management  support  are 
necessary  in  order  to  eventually  realize  the  benefits  of  OOD. 

2.3  Reuse 

Reuse  is  the  use  of  previously  acquired  concepts  (the  reuse  of  ideas  and  knowledge)  and 
objects  (the  reuse  of  particular  artifacts  and  components)  in  a  new  situation.  It  is  the  process 
of  building  software  systems  from  existing  software  rather  than  building  software  systems 
from  scratch.  Very  significant  process  has  been  made  in  the  evolving  field  of  software  reuse. 

The  main  motivation  to  reuse  software  artifacts  is  to  increeise  software  development  and 
maintenance  productivity;  this  leads  to  higher  quality,  more  reliable  software,  and  conserva¬ 
tion  and  preservation  of  software  engineering  expertise  (14:3).  Portability  is  a  characteristic 
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of  software  closely  related  to  reusability.  It  refers  to  the  extent  to  which  a  software  compo¬ 
nent  can  be  used  in  multiple  machine  environments.  Thus  reusability  includes  portability  in 
the  sense  that  portability  is  necessary  to  achieve  reusability  across  multiple  machine  envi¬ 
ronments  at  least  at  code  level. 

The  U.S.  DoD  software  engineering  community  is  in  its  pursuit  of  software  reuse,  and 
has  seen  evidence  that  the  software  reuse  principle,  when  integrated  into  acquisition  practices 
and  software  engineering  processes,  provides  a  basis  for  dramatic  improvement  in  the  way 
software  intensive  systems  are  developed  and  supported  over  their  lifecycle.  Availability 
of  the  Ada  language  has  spurred  interest  in  reuse,  and  Ada  serves  as  the  implementation 
language  in  many  reuse  projects.  At  the  highest  level,  the  DoD  vision  for  reuse  is  to  drive  the 
DoD  software  community  from  its  current  “re-invent  the  software”  cycle  to  a  process-driven, 
domain-specific,  architecture-centric,  library-based  way  of  constructing  software.  The  DoD’s 
long-term  strategy  is  to  lead  to  the  creation  of  a  true  “black-box”  components  industry  (28). 

There  is  great  diversity  in  the  software  engineering  technologies  that  involve  some  form 
of  software  reuse.  Typically,  reuse  involves  the  abstraction,  selection,  specialization,  rnd  in¬ 
tegration  of  artifacts,  although  different  reuse  techniques  may  emphasize  or  de-emphasize 
certain  of  these,  Krueger  partitioned  the  different  approaches  to  software  reuse  into  eight 
categories:  high-level  languages,  design  and  code  scavenging,  source  code  components,  soft¬ 
ware  schema,  application  generators,  very  high  level  languages,  transformation  systems,  and 
software  architecture,  analyzed  them  according  to  the  following  taxonomy  (22:137). 

•  Abstraction:  What  type  of  software  artifacts  are  reused  and  what  abstractions  are 
used  to  describe  the  artifacts? 

•  Selection:  How  are  reusable  artifacts  selected  for  reuse? 

•  Specialization  :  How  are  generalized  artifacts  specialized  for  reuse? 

•  Integration:  How  are  reusable  artifacts  integrated  to  create  a  complete  software  sys¬ 
tem? 
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2.3.1  Reuse  in  Design  and  Code  Scavenging.  The  reusable  artifacts  in  scavenging 
are  source  code  fragments.  The  abstractions  for  these  artifacts  are  informal  concepts  that 
a  software  developer  has  learned  from  previous  experience.  When  a  software  developer 
recognizes  that  some  part  of  a  new  application  is  similar  to  one  previously  written,  a  search  for 
existing  code  may  lead  to  code  fragments  that  can  scavenged.  Specialization  of  a  scavenged 
code  may  be  done  through  manual  editing.  Integrating  a  scavenged  code  into  a  new  context 
may  require  some  modification  of  the  fragment,  the  context,  or  both.  In  ideal  cases  of 
scavenging,  large  fragments  of  source  code  can  be  adapted  without  significant  modification. 
But  in  the  worst  case,  lots  of  time  can  be  wasted  understanding,  modifying,  and  debugging 
a  scavenged  code  rather  than  developing  the  equivalent  software  from  scratch. 

2.3.2  Reuse  in  Source  Code  Components.  Currently,  the  best  abstractions  for 
reusable  components  are  domain-specific  concepts,  such  as  those  found  in  the  math  libraries. 
The  area  of  code  reuse,  including  deliverable  code,  test  code,  simulation  code,  or  etc.  is  the 
highest  potential  for  near-term  payoff.  There  are  two  different  categories  of  code  components 
for  reuse  -  “passive  components”  or  “building  blocks”,  which  are  used  essentially  unchanged, 
and  “dynamic  components”  or  “generator”,  which  generate  a  product  for  reuse  (18:83-84). 
Although  selection  in  domain-specific  components  is  easy  since  components  can  be  classified, 
organized,  and  retrieved  using  well  defined  properties  of  the  domain,  the  ease  of  selection 
in  a  general-purpose  component  library  depends  on  the  degree  of  the  abstraction,  classifi¬ 
cation,  and  retrieval  schemes.  Generalized  components  with  construction-time  parameters 
represent  the  most  effective  approach  to  component  specification.  Reusable  components  can 
be  specialized  either  by  editing  the  source  code  directly  or  with  mechanisms  such  as  the 
Ada  generic  or  inheritance  in  object-oriented  languages.  Ada  generics  provide  a  level  of 
abstraction  that  isolates  the  software  developer  from  many  implementation  details.  Ada 
generics  can  be  parameterized  with  language  constructs  such  as  data  types,  data  objects, 
and  functions.  Module  interconnection  languages  such  as  Ada  typically  provide  the  frame¬ 
work  for  integrating  components.  Ada  can  integrate  source  code  components  written  in  C, 
FORTRAN,  and  eissembly.  Naming  and  name  binding  are  important  module  interconnection 


issues  in  component  reuse  since  reusable  components  are  constructed  independently  of  any 
particular  context,  which  can  present  problems  such  that  na.mes  imported  into  and  exported 
from  the  component  may  crash  or  be  incorrectly  bound  in  the  new  system.  Ada  is  a  particu¬ 
larly  good  candidate  for  implementing  reusable  components  since  Ada  provides  mechanisms 
to  overcome  some  of  these  naming  problems. 

2.3.3  Reuse  in  Software  Schemas.  The  sc^'/^ma  approach  emphasizes  the  reuse 
of  algorithms,  abstract  data  types,  and  higher  level  abstractions.  It  is  a  formal  extension 
to  reusable  software  components.  For  example,  some  algorithm  books  provide  a  library  of 
abstract  descriptions  for  many  basic  computer  science  algorithms  and  data  structures.  Pro¬ 
grammers  can  informally  use  these  abstractions  when  writing  source  code.  Large  schema 
libraries  are  difficult  to  use;  however,  automated  assistance  can  help  for  schema  selection. 
Schemas  are  typically  specialized  either  by  substituting  language  constructs,  code  fragments, 
or  specification  into  parameterized  parts  of  a  schema  or  by  choosing  from  a  predefined  enu¬ 
meration  of  options.  A  simple  approach  to  schema  integration  is  to  u.se  a  module  inter¬ 
connection  language.  For  example,  if  a  schema  instantiation  produces  Ada  package  code, 
an  instantiated  schema  can  be  treated  as  a  conventional  Ada  package.  More  sophisticated 
schema  integration  techniques  rely  on  semantic  specifications. 

2.3.4  Reuse  in  Software  Architecture.  Software  architectures  are  analogous  to  very 
large-scale  software  schemas.  Software  architectures,  however,  focus  on  subsystems  and  their 
interaction  rather  than  data  structures  and  algorithms. 

2.3.5  Reusability  in  an  Object-Oriented  Approach.  The  object-oriented  paradigm 
combines  design  techniqties  and  language  features  to  provide  strong  support  for  reuse  of 
software  modules.  Reuse  comes  in  a  variety  of  forms.  Some  of  the  reuse  in  the  object- 
oriented  paradigm  is  much  the  same  as  that  in  the  procedural  paradigm,  but  the.  object- 
oriented  paradigm  adds  an  additional  type  of  reuse. 


Every  time  an  instance  of  a  class  is  created,  reuse  occurs.  This  is  similar  to  the 
declaration  of  a  variable  of  a  specific  type.  The  major  difference  is  that  the  resulting  class 
instance  is  a  much  more  complex  structure  than  a  simple  variable.  An  instance  of  a  class 
provides  a  combination  of  data  structures  and  operators  on  those  data  structures.  This  is 
similar  to  (but  more  general  than)  library  reuse  with  the  conventional  paradigm. 

Inheritance  provides  levels  of  support  for  reuse  (21).  As  part  of  the  high-level  design 
phase,  inheritance  serves  as  a  means  of  modeling  generalization/specialization  relationships. 
These  relationships  appear  in  the  form  of  classifications.  A  chair  may  be  viewed  as  a  special 
type  of  furniture,  as  well  as  a  general  description  of  the  more  specific  categories  of  rocking 
chairs,  straight  chairs,  and  reclining  chairs.  This  high-level  use  of  inheritance  encourages  the 
development  of  meaningful  abstractions  which,  in  turn,  encourages  reuse. 

Often  in  actual  design,  the  presence  of  mid-level  abstractions,  such  as  table  and  chair, 
will  be  recognized  and  considered  separately.  The  availability  of  an  inheritance  relation 
enables  the  designer  to  “push  higher”,  to  identify  commonalty  among  abstractions,  and  to 
produce  higher-level  abstractions  (e.g.,  furniture)  from  this  commonality.  By  identifying  this 
commonality  and  moving  it  to  a  higher  abstraction,  it  becomes  available  to  be  reused  later 
in  the  current  design  or  in  future  designs.  Filing  cabinets  and  bookcases  may  be  identified 
later.  Much  of  their  description  (attributes  such  as  height,  weight,  color,  etc.)  may  already 
be  available  from  the  furniture  abstraction.  The  benefits  of  this  reuse  prompt  the  designer 
to  search  for  higher  and  higher  levels  of  abstraction. 

I 

I 

In  th^^  low-level  design  phase,  inheritance  supports  the  reuse  of  an  existing  class  ^ls  the 
basis  for  the  definition  of  a  new  class.  An  existing  piece  of  code  can  be  copied  to  a  new 
file  and  modified  to  fit  its  new  purpose.  This  inheritance  mechanism  does  not  establish  any 
connection  between  the  old  piece  of  code  and  the  new  code. 

For  example,  algorithm  reuse  involves  using  the  same  algorithm  across  data  structures. 
Using  the  data  abstraction  supported  by  object-oriented  technology,  such  an  algorithm  is 


implcmeiitecl  at  a  high  level  of  a  class  hierarchy  and  becomes  automatically  available  to 
subclasses. 

These  mechanisms  promote  reuse  by  means  of  interface  abstraction.  An  interface 
specification  is  the  most  abstract  reusable  artifact  of  a  software  system.  It  consists  of  a  set 
of  messages  that  embody  a  coordinated  set  of  behaviors.  Classes  whose  instances  perform  the 
role  implied  by  these  behaviors  must  provide  a  behavior  implementation.  These  instances 
can  then  be  used  wherever  this  common  behavior  is  expected. 

2.4  The  Features  of  Ada 

This  section  provides  a  quick  overview  of  the  advanced  features  of  the  Ada  'anguage. 
The  DoD  designed  Ada  as  a  general-purpose  language  intended  to  embody  and  er  force  the 
principles  of  software  engineering  in  hopes  of  lowering  the  cost  of  the  software  life-cycle. 
Ada’s  objectives  were  not  to  extend  the  realm  of  things  that  computers  can  do,  but  to 
provide  a  single  way  to  do  the  things  that  are  now  done  in  numerous  incom  iatible  but 
similar  languages  (13:38).  “Ada  is  a  design  language  that  is  suitable  for  the  design  and 
implementation  phases  of  the  software  life  cycle.  Ada  directly  embodies,  encourages,  and 
enforces  modern  software  engineering  principles  and  methodologies”  (30:163). 

2,4.1  The  Object  Oriented  Capabilities  of  Ada.  Ada  has  been  traditionally  associ¬ 
ated  with  Object-Oriented  Design  (OOD),  which  was  exploited  by  Booch  (7).  However,  OOD 
can  be  extended  more  easily  and  smoothly  through  Object-Oriented  Programming  (OOP), 
which  has  basically  two  additional  features,  mAcri/ance  and  polymorphism,  that  cannot  be 
fully  extended  by  object-based  programming  language  such  as  Ada.  Ada’s  suppct  for  the 
two  additional  features  is  less  systematic  than  that  found  in  C-f-f ,  which  fully  supports  these 
features.  Alternatively,  one  might  think  of  OOP  in  terms  of  two  programming  paradigms, 
which  will  be  associated  with  OOP: 

•  variant  programming:  new  abstracts  may  be  constructed  from  existing  ones  so  that  the 

programmer  need  only  specify  the  differences  between  the  new  and  old  abstractions. 
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•  class-wide  programming:  classes  of  related  abstractions  may  be  handled  in  a  unified 
fashion,  such  that  the  programmer  may  systematically  ignore  their  differences  when 
appropriate  (1). 

Ada  provides  the  basis  for  supporting  object-oriented  programming  with  variant  and  class¬ 
wide  programming  in  the  form  of  derived  types,  subtypes,  packages,  and  generic  units. 
Each  of  these  has  its  limitations  such  as  type  incompatibility  by  deriving  from  the  parent 
types,  narrowing  their  applicability  by  subtyping,  recompilation  of  the  original  abstraction 
by  breaking  the  original  abstraction,  and  complicated  generic  parameters.  Ada  supports 
several  forms  of  static  polymorphism:  generic  formal  types,  subprogramming  overloading, 
and  implicit  conversion  of  class-wide  (real  and  integer)  literals. 

Recognizing  limitations,  the  Ada  9X  program  is  preparing  a  refined  version  of  Ada  to 
update  the  Ada  standard  in  accordance  with  ANSI  and  ISO  procedures  under  the  Ada  Joint 
Program  Office  (AJPO).  The  current  Ada  9X  review  process  is  adding  changes  to  improve 
Ada’s  use  in  00  development,  programming-in-the-large  and  real-time  programming.  Ada 
9X  will  provide  improved  support  for  00  development  in  several  ways  (1): 

•  subprograms  as  objects:  dynamically  selecting  subprograms 

•  reducing  the  need  for  recompilation 

•  programming  by  specialization/extension:  defining  a  new  entity  which  can  be  used 
anywhere  the  original  one  could  be,  in  exactly  the  same  way  without  modification  of 
the  original  one. 

Subprograms  as  objects  provides  the  ability  to  associate  operations  (subprograms)  with 
objects,  and  to  dynamically  select  and  execute  those  operations,  which  is  the  basis  for 
run-time  polymorphism.  Programming  by  specialization/extension  and  reducing  the  need 
for  recompilation  provides  the  ability  to  extend  derived  reuse,  which  is  the  basis  for  the 
inheritance  mechanism. 


2.4-2  The  Reusability  of  Ada.  The  Ada  programming  language  has  several  mech¬ 
anisms  which  aid  in  the  specification  and  development  of  reusable  code.  (19:486) 

•  Ada  supports  reusability  through  the  package  concept.  This  is  a  mechanism  whereby 
one  can  define  an  Abstract  Data  Type  (ADT),  and  it  supports  the  notion  of  information 
hiding. 

•  Ada  supports  reusability  through  generics  (generic  procedures  in  Ada  are  mechanisms 
which  preserve  the  virtues  of  typing,  while  eliminating  the  negative  aspects).  Generics 
can  be  procedures  or  packages  -  but  reusable  generic  packages  are  a  more  powerful 
concept  than  that  of  procedures. 

2.4.3  Foreign  Language  Interface.  One  unique  feature  of  Ada  is  its  ability  to  in¬ 
terface  to  other  languages.  The  interface  pragma  allows  an  Ada  program  to  call  a  program 
written  in  another  language  such  as  C,  FORTRAN  or  assembly  language.  An  Ada  program 
calling  a  subprogram  written  in  another  language  must  include  a  declaration  for  that  subpro¬ 
gram,  written  in  the  usual  Ada  notation  for  subprogram  declarations.  The  actual  code  in  the 
other  language  plays  the  role  of  an  Ada  subprogram  body,  so  the  Ada  program  includes  an 
interface  pragma  instead  of  the  actual  subprogram  body  (11:807).  An  implementation  may 
restrict  the  use  of  the  interface  pragma.  For  example,  it  might  establish  a  correspondence 
between  certain  predefined  Ada  types  and  types  in  the  other  language  and  require  that  each 
subprogram  parameter  and  function  result  belong  to  one  of  these  types. 

2.5  The  Features  of  C++ 

C-l")-  is  a  strongly-typed  language  developed  by  Bjarne  Stroustrup  at  AT&T  Bell 
Laboratories  as  an  extension  of  C.  The  primary  difference  between  C-f-f  and  C  is  the  support 
C-b-f  provides  for  the  following:  (23:580) 

•  Inlining  and  overloading  of  functions. 

•  Ability  to  provide  default  argument  values. 
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•  Argument  pass-by-reference  (in  addition  to  the  C  language  default  pass- by- value). 

•  Support  of  template  functions  and  classes. 

•  Support  of  abstract  data  types  by  providing  for  information  hiding  and  the  definition 
of  a  public  interface. 

•  Support  for  object-oriented  programming. 

The  language  supports  object-oriented  concepts  such  as  abstract  data  type,  inheritance, 
polymorphism,  and  dynamic  binding  (20:396). 

•  Abstract  Data  Type:  C-r-f  provides  two  constructs  for  defining  an  ADT.  The  first  one 
is  an  extension  of  the  struct  construct  and  the  other  is  the  class  construct. 

•  Inheritance:  C-|— f-  allows  the  hierarchy  of  class  definitions  to  inherit  both  method  and 
instance  variables  from  existing  class  definitions. 

•  Overloading!  Overriding  and  Dynamic  Binding:  C-f-l-  allows  overloading  of  function 
names  and  operators.  It  allows  single  polymorphism  but  not  parametric  polymorphism 
(or  genericity)  which  is  supported  by  many  object-oriented  languages  and  also  Ada. 
C-h-b  also  supports  dynamic  binding  through  virtual  functions. 

2.6  AdalC++  Similarities  and  Contrasts 

Programming  language  selection  is  not  the  major  cost  driver  in  a  software  development 
environment  (14).  But  languages  facilitating  software  engineering  methods  and  principles 
can  produce  software  easier  to  learn  and  understand,  easier  to  reuse,  easier  to  change  and 
maintain,  and  easier  to  interface  with  other  languages  and  CASE  tools.  Both  Ada  and 
C-I-+  are  general-purpose  languages  of  roughly  similar  power  and  have  features  that  modern 
software  engineering  practice  considers  indispensable:  modularity,  information  hiding,  ab¬ 
straction,  structuring  tools  for  large  programs,  and  various  mechanisms  for  parameterizing 
software  components.  The  following  comparison  and  contrasts  between  Ada  and  C-I-+  is 
based  on  current  versions  of  the  languages.  For  Ada,  the  language  is  defined  by  ANSI/MIL- 


\ 
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STD-1815A-1983.  For  C++,  the  language  is  defined  by  version  2.1  of  the  AT&T  CFRONT 
translator. 

Comparing  Ada  and  C++  is  not  easy,  if  for  no  other  reason  than  C++  is  a  language  in 
flux  for  which  there  is  no  stable  definition,  no  approved  standard  reference,  and  no  translator 
validation. 

C++  requires  more  knowledge  than  Ada,  but  this  knowledge  is  ill-defined  at  the  in¬ 
terface  between  environment  and  language.  This  reduces  portability  and  thus  increases 
maintenance  costs  more  than  comparable  Ada  software.  C++  software  is  less  reliable  than 
Ada  since  arrays  in  C++  are  closely  related  to  pointers,  and  the  indexing  operation  is  de¬ 
scribed  directly  in  terms  of  pointer  arithmetic.  The  generic  facility  of  Ada  is  an  excelleiit 
model  of  type  parameterization  to  maximize  software  reuse  rather  than  C++,  although  C++ 
provides  a  template  which  is  close  in  spirit  to  Ada  generics.  C++  emphasizes  ease  of  writing 
rather  than  ease  of  reading.  This  makes  C++  programs  harder  to  transmit  and  maintain 
(33:15).  Ada  has  demonstrated  maintainability  and  reliability  for  large-scale  development. 
Ada  is  safer  but  less  flexible  than  C++.  Currently,  Ada  has  not  been  used  extensively  in 

j 

several  key  areas.  A  couple  of  important  changes  planned  include  extending  Ada’s  data  als- 

l 

straction  capabilities,  adding  object-oriented  programming  features,  and  improving  control 
over  concurrency  for  real-time  applications  (1). 

] 

C++  is  already  a  widely  accepted  object-oriented  language  in  the  commercial  area  and 
is  becoming  even  more  popular  since  it  has  a  C  and  Unix  base.  C++  is  highly  flexible  and 
therefore  less  safe  than  Ada.  The  emerging  C++  standards  will  help  to  increase  portability 
and  maintainability  of  C++. 

Table  2.1  shows  some  important  language  features  and  their  relative  support  by  the 
two  languages  (6:2-9).  Interfacing  well  with  other  languages  is  an  important  attribute  of 
any  programming  language.  The  C++  language  can  invoke  directly  C  run  time  libraries 
and  existing  C  software  with  C  interfaces.  Ada  defines  an  optional  pragma  interface  for 
interfacing  to  other  languages.  Some  advantages  depend  on  their  compiler  support. 


2-17 


Feature 

Ada(only) 

Ada{+) 

Both(=) 

c++(+) 

C++(only) 

Parameterized  Types 

X 

Safe  Types 

X 

Error  Handling 

X 

Concurrency 

X 

External  Interrupts 

X 

Compilation  Management 

X 

Strong  Types 

X 

Modularity 

X 

External  I/O 

X 

Extensible  Typing 

X 

Overloading 

X 

Multilingual  Support 

X 

Polymorphism 

X 

Inheritance 

X 

Subprogram  Variables 

X 

Conditional  Compilation 

X 

Table  2.1.  Ada  and  C++  Support  for  Key  Language  Features 


2.6.1  Features  Where  Ada  has  an  Advantage.  The  following  paragraphs  discusses 
the  features  where  the  Ada  language  has  an  advantage  over  the  C++  language  (6:2-10). 


•  Parameterized  Types  :  A  parameterized  mechanism  is  useful  for  building  strongly 
typed  reusable  component  libraries.  Ada  provides  this  useful  support  through  generics. 
Although  some  users  of  the  present  versions  of  the  C++  language  provide  their  own 
template  preprocessors  for  this  feature,  it  is  not  available  commercially  in  C++. 

•  Safe  Types  :  Ada  provides  run-time  checks,  array  subscript  variables  and  ranges.  C++ 
does  not  provide  bounds  checking.  C++  provides  flexible  dynamic  memory  allocation 
which  must  be  used  carefully  to  prevent  problems. 

•  Error  Handling  :  For  reliable  and  maintainable  systems,  a  reliable  standard  mechanism 
for  handling  errors  is  essential.  Ada  provides  user  defined  exceptions  and  some  useful 
predefined  exceptions  for  error  handling. 
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•  Concurrency  :  Ada  provides  support  for  concurrency  with  tasks  for  the  efficient  im¬ 
plementation  of  a  large  system. 

•  External  Interrupts  :  Ada  provides  a  standard  mechanism  for  handling  interrupts  from 
the  external  environment  as  task  entry  points. 

•  Compilation  Management  :  Efficient  management  of  compilation  dependencies  and 
good  compilation  dependency  information  can  not  only  save  large  amounts  of  com¬ 
puter  and  human  resources  but  also  simplify  the  creation  of  software  tools  such  as 
configuration  management  tools,  test  generator  and  code  analysis  tools.  The.se  compi¬ 
lation  dependencies  are  well  defined  in  Ada,  but  not  as  well  defined  in  C-f-f-. 

2.6.2  Features  Where  C++  has  an  Advantage.  Listed  below  are  the  features  where' 
C-f-f  language  has  an  advantage  over  the  Ada  language.  (6:2-10) 

•  Inheritance  :  C-f-f  supports  both  single  and  multiple  inheritance.  This  feature  is 
not  available  in  Ada.  The  C-f-f  inheritance  is  more  powerful  than  the  derived  typed 
mechanism  in  Ada.  Ada  inheritance  is  expected  to  appear  in  the  Ada  9X  language. 

•  Polymorphism  Languages  :  C-f-f  supports  polymorphism  through  its  inheritance  mech¬ 
anism.  Inheritance  and  polymorphism  are  expected  in  Ada  9X. 

•  Subprogram  Variables  :  C-f-f  has  pointers  to  functions.  Pointers  to  subprograms  are 
expected  in  Ada  9X. 

•  Conditional  Compilation  :  C-f-f  supports  conditional  compilation,  via  the  preprocessor 
mechanism. 

2.7  Ada  Interfacing  (Binding)  with  C++/C 

In  general,  translating  programs  from  other  languages  into  Ada  is  straightforward  if 
the  source  language  is  one  of  the  block-oriented  languages  such  as  C.  However,  it  is  more 
desirable  to  make  use  of  existing  subprograms  or  libraries  developed  in  some  other  language 
from  inside  Ada  programs  without  having  to  translate  everything  into  Ada.  There  is  a  need 
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in  development  of  software  systems  for  utilization  of  capabilities  which  are  not  inherently 
supported  by  a  chosen  development  language.  For  example,  if  a  graphics  capability  was 
required,  the  programmer  typically  used  a  specific  vendor’s  graphics  interface.  In  order  to 
overcome  this  deficiency  in  a  cost-effective  manner,  bindings  are  required.  An  interfacing 
(binding)  is  a  set  of  code  which  allows  the  use  of  software  and  hardware  that  provides  some 
capability  required  for  a  given  application.  In  the  past,  software  systems  tended  to  be  built 
around  a  specific  product,  which  decreased  portability.  Standard  interfaces  were  required 
to  provide  portability.  Ada  provides  mechanisms  that  allow  the  programmer  to  specify 
interfacing  which  is  no  longer  limited  to  a  single  machine.  This  section  presents  the  naming 
convention,  parameter  passing  method,  and  an  approach  to  making  existing  libraries  and 
programs  written  in  C-f-f/C  usable  from  Ada. 

2.7.1  Ada  Interface.  Ada  has  a  complicated  naming  convention  for  its  objects 
that  can  be  accessed  from  another  language.  For  example,  subprogram  names  are  usually 
encoded  as  follows:  (12:21-25) 

_A_subprogramnameLLXcc.parent 

where: 

subprogramname  is  the  subprogram  name. 

LL  is  the  line  number  of  its  definition. 

X  is  S  if  defined  in  the  spec  and  B  for  the  body. 

cc  is  the  character  number  of  its  definition. 

parent  is  ♦^he  name  of  the  parent  unit,  without  the  _A_  prefix. 

To  access  a  Ada  object,  a  user  must  be  able  to  modify  the  Ada  source  code  to  know 
where  the  subprogram  is  declared.  Another  big  problem  with  the  Ada  naming  convention 
is  that  when  you  change  the  location  of  the  subprogram  in  its  source  program,  the  external 
name  changes.  Fortunately,  Ada  provides  the  pragma  that  you  can  use  to  specify  an  un¬ 
changing  external  symbol  name  for  variable  and  function.  These  pragmas  are  externaLname, 
interface,  and  interface.name.  The  pragma  EXTERNAL.NAME  allows  users  to  specify  an 
external  symbol  name,  or  linkage  name,  for  Ada  variables  or  subprograms  so  that  it  can 
be  accessed  from  another  language.  The  pragma  INTERFACE  allows  users  to  call  routines 
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written  in  another  language.  The  pragma  INTERFACE-NAME  allows  users  to  access  ex¬ 
ternal  objects  such  as  common  blocks,  C  global  variables,  and  routines  written  in  another 
language. 

Ada  allows  data  to  be  passed  by  reference  or  by  value  using  the  formal  argument 
mode.  To  pass  a  parameter  by  reference  users  must  use  the  in  out  parameter  mode.  To  pass 
a  parameter  by  value  users  must  use  the  in  mode.  However,  arrays  and  records  must  always 
be  passed  by  address. 

There  are  a  couple  of  restrictions  with  the  pragma  interface  (12:24). 

•  The  types  of  parameters  for  C  routines  must  be  scalar,  access  or  the  predefined  type 

address,  and  all  parameters  must  have  mode  in. 

•  The  return  types  are  limited  to  scalar,  access  or  the  predefined  type  address. 

2.7.2  C  Interface.  C  has  the  single  naming  convention  for  external  symbols,  which 
include  function  names  and  global  variables.  The  C  compiler  prepends  an  underscore  char¬ 
acter  to  external  symbols.  Additionally,  function  names  and  global  variables  produced 
by  the  C  compiler  are  unrestricted  in  length  and  case  sensitive  (12:15-16).  For  example,  the 
external  symbols  produced  for  the  following  code  fragment  are  .add  and  .num3. 

int  add(  int  numl,  int  num2) 

{ 

extern  int  num3; 

return  (numl  -f  num2  -|-  num3); 


C  functions  basically  pass  all  parameters  except  arrays  by  value,  which  means  that 
only  the  contents  of  a  parameter  are  passed  to  the  called  routine,  not  its  address.  Arrays 
are  passed  by  reference.  However,  C  provides  two  operators  users  can  use  to  work  around 
this  parameter  passing  method:  address  operator  (&;)  and  indirection  operator  (*). 
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2.7.3  C++  Interface.  Like  Ada,  C++  generates  symbols  that  do  not  simply 
have  underscores  prepended  and  appended  to  a  function  name.  Although  a  data  types  and 
function  parameter  passing  method  in  C++  are  basically  the  same,  function  symbol  names 
usually  have  a  return  type  and  parameter  data  types  encoded  in  them.  Fortunately,  C++ 
provides  a  linkage  specifier  that  causes  C++  to  generate  a  symbol  name  that  conforms  to 
the  C  language  interface.  The  AT&T  C++  Language  System  Product  Reference  Manual 
describes  the  following  information  about  the  linkage  specifier  (3:40).  Linkage  to  non-C++ 
code  fragments  can  be  achieved  using  the  following  linkage  specifier. 

extern  string-literal  declaration 
extern  string  literal  {declaration-list} 
where: 

string-literal  can  be  “C”  or  “C++”  to  indicate  whether  a 

declaration  should  have  C  or  C++  linkage.  Default  is  C++ 
declaration  is  a  function  or  variable  declaration  ! 
declaration-list  is  a  list  of  function  and  variable  declarations 

i 

Linkage  specifications  nest.  A  linkage  specification  does  not  establish  a  scope.  A 
linkage-specification  may  only  occur  in  file  scope.  A  linkage-specification  for  a  class  applies 
to  non-member  functions  first  declared  within  it.  A  linkage-specification  for  a  function  also 
applies  to  functions  declared  within  it.  A  linkage  declaration  with  a  string  that  is  unknown 
to  the  implementation  is  an  error. 

2.7.4  Ada  Binding  to  C++/C  Routines.  Use  of  the  Ada  language  facilitates  porta¬ 
bility,  as  compared  to  other  languages.  The  features  of  the  Ada  language  support  portability 
through  abstraction  and  information  hiding.  Ada  packaging  allows  the  encapsulation  of  both 
data  and  operations  into  a  single  unit,  the  enforcement  of  strong  typing  and  information  hid¬ 
ing,  the  separation  of  the  specification  and  body,  and  the  isolation  of  the  system  dependent 
features.  The  Ada  package  for  calling  the  library  functions  or  existing  code  gives  the  pro¬ 
grammer  b2isically  the  same  functional  entities  and  objects  as  the  original. 
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There  is  a  series  of  procedures  which  are  required  to  successfully  develop  a  binding. 
For  a  complete  Ada  interface  to  a  library  and  existing  codes  using  the  same  subprogram  and 
variable  names  provided  in  the  original  C++/C  version,  the  following  six  steps  are  necessary 
(34:156): 

•  Create  parallel  data  types. 

•  Interface  to  external  routines. 

•  Interface  to  external  data. 

•  Link  to  external  libraries. 

•  Test/Debug  the  interface. 

•  Optimize  the  interface. 

2.7.4. 1  Create  parallel  data  types.  Whenever  access  to  a  routine  or  variable 
declared  in  an  alternative  language  is  required,  any  Ada  variable  used  in  conjunction  with 
the  subroutine  or  variable  is  of  a  compatible  data  representation  in  both  languages.  When 
creating  Ada  data  types  to  parallel  the  types  of  other  languages,  the  user  should  not  assume 
that  the  types  or  structures  have  the  same  implementation  in  Ada,  even  if  they  have  the 
same  name;  that  is,  a  data  structure  declared  in  Ada  must  be  identical  to  a  data  structure 
declared  in  C++/C. 

A  way  of  creating  parallel  data  types  is  to  use  a  priori  knowledge.  There  are  some 
types  that  the  programmer  knows  are  parallel  between  two  language  implementations  from 
reading  the  vendor’s  documentation.  Neither  Ada  nor  C++/C  compilers  are  required  to  use 
a  particular  size  to  represent  any  particular  type,  and  an  implementation  is  free  to  choose  a 
representation  based  on  hardware  considerations. 

Another  way  of  creating  parallel  data  types  is  to  use  Ada  representation  specifications. 
In  Ada,  we  can  define  an  exact  duplicate  of  the  physical  layout  of  any  data  type  in  another 
language  once  it  is  known.  It  can  be  done  by  Ada  representation  clauses.  When  the  underly- 
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ing  representation  of  a  type  has  no  analogue  in  one  language,  the  data  type  can  be  defined  by 
the  programmer  using  Ada  representation  specifications  and  UNCHECKED.CONVERSIONs. 

The  conversion  of  six  differe;nt  type  categories  can  be  described  as  follows.  (41:PG4-2) . 

•  Simple  Types:  There  are  some  simple  Ada  predefined  types  that  correspond  to  C  simple 
types.  When  C++/C  programs  contain  ambiguous  assignments  or  uses  of  such  types 
or  of  integer/address  conversion,  the  generic  function  UNCHECKED.CONVERSION 
offers  a  method  for  controlled  easing  of  type  conversion.  For  example,  to  implement 
an  Ada  type  to  match  a  C++/C  int  type,  a  programmer  could  specify  as  follows: 

-  type  C-int  is  range  -(2++15)  ..  (2**15)  -  1; 

-  for  CJnt’size  use  16; 

-  CJnt-use  :  CJnt; 

The  first  line  represents  a  type  that  has  the  same  range  as  the  int  type  in  C++/C.  The 
second  line  ensures  that  the  same  amount  of  storage  is  used.  The  third  line  declares  a 
variable.  Other  simple  types  with  different  representations  can  be  constructed  similarly. 

•  Record  Types:  The  same  basic  approach  can  be  taken  in  the  representation  of  record 
types  as  with  simple  types.  Both  Ada  and  C++/C  associate  the  record  label  with 
a  base  address  from  which  offsets  to  access  individual  components  of  records  are  cal¬ 
culated.  In  Ada,  as  long  as  the  record  is  composed  of  equivalent  simple  data  types, 
the  offsets  will  be  calculated  similarly,  and  record  structures  will  be  identical.  When 
storage  conventions  are  not  so  conveniently  arranged,  Ada  representation  specification 
can  be  used  for  constructing  records. 

•  Array  Types:  Ada  "md  C-1-+/C  arrays  are  stored  in  row-major  order.  When  defining 
Ada  array  types  that  are  parallel  to  C-1--1-/C  array  types,  the  standard  representation 
of  an  array  in  both  languages  is  to  associate  the  array  label  with  the  first  component 
and  use  this  location  to  calculate  an  offset.  The  individual  components  should  be  com- 


patible  structures.  Otherwise,  representation  specifications  should  be  used  to  assure 
that  indiv'  al  component  representations  are  identical. 

•  Dynamic  Array  Types:  In  C++/C,  the  size  of  a  dynamic  array  is  calculated  by  the 
user,  based  on  data  known  only  to  the  user.  C++/C  arrays  always  start  at  index  0 
while  Ada  arrays  start  with  any  index.  Passing  arrays  from  C++/C  to  Ada  is  possible 
by  creating  an  appropriate  subtype  for  the  value.  If  a  C++/C  array  is  passed  and 
must  be  preserved  over  an  open  scope,  a  fixed-length  array  must  be  used  in  the  Ada 
program,  making  the  Ada  array  at  least  as  large  as  any  possible  C-h-f/C  parameter. 

•  Pointers  and  Address  Types;  Pointer  and  address  types  are  implementation-specific. 
But  Ada’s  tactic  of  using  host  conventions  usually  allows  the  use  of  Ada  pointer  and 
address  types  parallel  to  their  C-|--f/C  counterparts.  Otherwise  Ada  representation 
specifications  can  be  used  to  tailor  the  size  and  range  of  the  data  type. 

•  String  Types  :  A  character  string  in  C-I--I-/C  is  represented  by  a  pointer  to  the  first 
character  in  an  array  of  bytes.  By  convention,  strings  in  C-f-f/C  are  terminated  by 
a  null  character  and  store  no  explicit  length.  In  Ada  however,  a  string  is  represented 
by  a  packed  array  of  type  CHARACTER  with  the  maximum  number  of  components 
specified  as  part  of  type.  A  parallel  type  can  be  created  using  a  declaration  in  Ada  as 
follows: 

-  type  C-String  is  access  STRING  (L.lNTEGER’Ly^ST) 

2.7.4. 2  Interface  to  external  routines.  Once  parallel  types  have  been  estab¬ 
lished,  the  next  step  is  to  gain  access  to  external  routines  provided  in  the  interface  target 
package.  This  is  accomplished  in  a  two  stage  procedure:  first,  equivalent  Ada  subprogram 
specifications  are  written,  and  second,  the  linkage  to  the  external  routine  is  declared.  The 
first  step  can  be  a  simple  mapping  of  the  external  routine’s  name  and  parameters  into  an 
Ada  subprogram  specification  or  can  involve  the  development  of  code  to  make  the  behavior 
of  the  external  routine  compatible  with  Ada.  The  second  step  is  accomplished  through  use 
of  the  pragma  INTERFACE  &nd  pragma  INTERFACF.NAME. 
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2.7, ^.3  Interface  to  external  data.  The  third  step  when  building  a  complete 
package  from  an  existing  C++/C  library  and  program  is  to  gain  access  to  external  variables 
declared  in  C++/C  from  Ada.  Some  Ada  compilers  contain  a  pragma  which  allows  the  ac¬ 
cessing  of  external  objects  directly,  while  others  require  the  programmer  to  build  an  external 
routine  which  returns  the  required  data  object  as  a  parameter  (34:159). 

For  example,  the  following  programs  illustrate  interfaciiig  between  Ada  and  C. 

C  program: 

•  ••  I 

char  *gets  (); 
int  atoi  (); 
int  servicejiumber; 
extern  void  ada_put  (); 
test  0 
{ 

char  buf[80]; 

printf(’’  Enter  an  integer  here:  ”); 
get  (buf); 

servicejiumber  =  atoi  (buf); 
ada-put  (service  Jiumber) ; 

waddch( window  win,char  []) 

{ 

}  . 

The  print/ call  was  replaced  with  ADA_PUT  and  an  Ada  package  containing 
the  procedure  ADA_PUT  and  interface  declarations  for  the  C  entities  were 
written  as  follows. 

with  language; 
package  CJnterface  is 


sei  vice  Jiumber  :  integer;  | 

pragma  interfacejiame(servicejiumber,C.5UBP_Prefix  &  ’’servicejiumber”) 

procedure  waddstar(win  :  window;  S  :  address); 
procedure  c.waddstr  (win  :  window;  str  :  address); 
pragma  interface(  C,  C.waddstr); 

pragma  interfacejiame(C_waddstr,  C-SUBPJPREFIX  &  ’’waddstr”); 
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procedure  ADA_PUT(I  :  integer); 
pragma  external  (C,  ADA_PUT); 

pragma  external_name(ADA_PUT,  C-PREFIX  h  ’’ada.put”); 

procedure  main; 
pragma  interface(C,main); 

pragma  interface_name(main,  C-SUBP_PREFIX  &  "test”); 

end  C-interface; 
package  body  C_interface  is 


-this  intermediate  Ada  module  will  convert  an  Ada  string 
-input  into  a  c-string  format  before  calling  the  C  routine 
procedure  waddstr(win  :  window;  S:  string)  is 
T:  string(l..(S’last  +  1)); 

begin 

T(l..S’last)  :=  S; 

T(S’last  +  1)  ;=  ascii. mil; 
c-waddstr(win,  T’address); 
end  waddstr; 

procedure  ADA.PUT  (I  :  integer)  is 
begin 

put(I); 
end  ADA.PUT; 
end  C-interface; 

Now  a  simple  Ada  “wrapper”  to  call  the  original  C  functions  is  written 
so  that  the  linker  a.ld  can  resolve  all  the  references  in  the  modules 
and  perform  its  usual  elaboration  order  checks. 

with  C-interface;  use  CJnterface; 
procedure  driver  is 

win  :  window; 

begin 

main; 

waddstr(win,”hellow” ); 
end  Driver; 


8. 7.4. 4  Link  to  External  Libraries.  The  fourth  step  in  the  Ada  interface  is 
the  ability  to  link  the  routines  and  data  types  built  in  the  previous  steps  with  the  external 
libraries.  It  is  typically  required  to  place  the  names  of  the  external  object  files  in  the  link 
path.  For  example,  illustrated  programs  compiling  both  the  C  and  Ada  portions  can  be  done 
by  compiling  the  C  portion  first,  then  using  the  Ada  linker  to  construct  the  ‘main’  program 
driver  and  the  C  objects  in  the  link. 

2.7. 4-5  Test/ Debug  the  Interface.  The  fifth  step  is  testing  and  debugging  the 
binding.  Since  a  good  binding  will  be  used  by  a  wide  variety  of  software  systems,  the  testing 
and  debugging  should  be  done  thoroughly  in  order  to  construct  a  reliable  system. 

2.7.4. 6  Optimize  the  Interface.  The  final  step  in  the  interface  process  is 
to  reduce  the  overhead  resulting  from  frequent  subprogram  calls  to  intermediate  routines 
written  in  Ada.  The  predefined  pragma  INLINE  provides  the  solution. 

2.7.5  Program  Conversion.  One  modular  approach  is  to  write  an  Ada  “wrap¬ 
per”  program  that  surrounds  the  subprograms  in  another  language  and  allows  them  to  be 
gradually  converted  (41:PG4-12).  Pragma  INTERFACE  And  pragma  INTERFACE.NAME 
are  useful  for  this  gradual  replacement  with  pragma  EXTERNAL  and  pargma  EXTER- 
NAL.NAME  that  allow  subprograms  in  other  languages  to  call  Ada  subprograms,  exactly 
the  reverse  of  the  INTERFACE  and  INTERFACE.NAME  pragmas. 

The  real  benefit  for  the  user  is  that  new  portions  of  large  programs  can  be  developed  in 
Ada,  but  existing,  tested,  working  code  need  not  be  replaced  wholesale.  Individual  modules 
can  be  replaced  by  newly  developed  Ada  code  without  undue  restrictions  on  the  language 
of  calling  or  called  subprograms.  An  additional  benefit  is  that  once  subprogram  parameters 
are  defined  in  Ada,  the  compiler  will  perform  its  usual  type  checking  across  subprograms. 
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2.8  The  MICROSTICK 


The  MICROSTICK  is  a  professional  high  quality  point  and  select  device.  One  of  its 
standard  features  includes  a  resolution  of  1  part  in  4096  and  six  types  of  movement.  These 
features  allow  users  to  change  gears  and  use  the  MICROSTICK  for  both  high-resolution 
accuracy  and  fast  poiniing  speed.  The  MICRGSTICK  is  connected  to  a  computer  or  a 
terminal  via  a  25-pin  RS232  connector.  The  MICROSTICK  outputs  an  18  byte  string  of 
ASCII  characters.  The  outputs  of  MICROSTICK  are  described  in  the  table  2.2.  Byte  1 
corresponds  to  a  delimiter,  Byte  2  describes  the  state  of  button  2,  etc. 


Byte 

Byte  1 

Byte  2 

Byte  3 

Byte  4 

Byte  5 

Byte  6 

What 

Delimiter 

Button  1 

Button  2 

Button  3 

Example 

$ 

0 

1 

0 

Byte 

Byte  7 

Byte  8-11 

Byte  13-16 

Byte  17-18 

What 

X  value 

y  value 

Delimiter 

Example 

1513 

0028 

[cr][lf] 

Table  2.2.  Outputs  of  MICROSTICK 

This  output  allows  easy  interface  to  a  microcomputer  or  a  terminal.  In  addition,  the 
MICROSTICK  microprocessor-based  design  allows  for  user-specified  models  of  operations 

i 

that  permit  eeisy  adaptation  to  most  applications.  The  user’s  manual  describes  the  MICRO¬ 
STICK  and  suggests  ways  to  realize  its  full  potential. 

The  MICROSTICK  can  be  controlled  by  Graphics,  CAD/CAM  or  Text  Editing  soft¬ 
ware.  Hence,  software  controlling  the  MICROSTICK  is  a  good  candidate  for  use  in  this 
research. 

2.9  Summary 

This  chapter  has  introduced  the  features  of  the  object-oriented  paradigm,  software 
reuse,  the  features  of  Ada  and  C-I--1-  languages,  and  the  MICROSTICK. 

The  object-oriented  paradigm  represents  a  more  intuitive  way  to  program  than  using 
procedurally  oriented  techniques.  The  object-oriented  approach  is  based  upon  the  concepts: 
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objects,  clcisses,  abstraction,  inheritance,  encapsulation,  polymorphism,  and  dynamic  bind¬ 
ing.  The  object-oriented  paradigm  offers  a  way  to  manage  the  complexity  inherent  in  a 
software  system,  and  supports  the  goals  and  principles  of  software  engineering. 

Reuse  is  the  use  of  previously  acquired  concepts  (the  reuse  of  ideas  and  knowledge) 
and  objects  (the  reuse  of  particular  artifacts  and  components)  in  a  new  situation.  It  is  the 
process  of  building  software  systems  from  existing  software  rather  than  building  software 
systeims  from  scratch.  The  main  motivation  to  reuse  software  artifacts  is  to  increase  software 
development  and  maintenance  productivity  in  order  to  obtain  higher  quality,  more  reliable 
software,  and  conserve  and  preserve  software  engineering  expertise.  There  is  a  great  diversity 
in  the  software  engineering  technologies  that  involve  some  form  of  software  reuse.  Typically, 
reuse  involves  the  abstraction,  selection,  specialization,  and  integration  of  artifacts,  although 
different  reuse  techniques  may  emphasize  or  de-emphasize  some  of  these. 

Programming  language  selection  is  not  the  major  cost  driver  in  a  software  development 
environment.  But  a  language  facilitating  software  engineering  methods  and  principles  can 
produce  software  easier  to  learn  and  understand,  easier  to  reuse,  easier  to  change  and  main¬ 
tain,  and  easier  to  interface  with  other  languages  and  CASE  tools.  Both  Ada  and  C-f-h  are 
general-purpose  languages  of  roughly  similar  power.  Both  have  features  that  modern  soft¬ 
ware  engineering  practice  considers  indispensable  such  as  modularity,  information  hiding, 
abstraction,  structuring  tools  for  large  programs,  and  various  mechanisms  for  parametriz¬ 
ing  software  components.  C-f  +  requires  more  knowledge  than  Ada,  but  this  knowledge  is 
ill-defined  at  the  interface  between  environment  and  language.  This  reduces  portability  and 
thus  Increases  maintenance  costs  over  comparable  Ada  software.  C-f-f  software  is  less  reli¬ 
able  than  Ada  since  arrays  in  C-f-f  are  closely  related  to  pointers,  and  the  indexing  operation 
is  described  directly  in  terms  of  pointer  arithmetic.  The  generic  facility  of  Ada  is  an  excel¬ 
lent  model  of  type  parameterization  to  maximize  software  reuse,  although  C-f-f  provides  the 
template  which  is  close  in  spirit  to  Ada  generics.  C-f-f  emphasizes  ease  of  writing  rather 
than  ease  of  reading.  This  makes  C-f-f  programs  harder  to  transmit  and  maintain.  Ada  is 
safer  but  less  flexible  than  C-f-f. 
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Translating  programs  from  other  languages  into  Ada  is  straightforward  if  the  source 
language  is  one  of  the  block-oriented  languages  such  as  C.  However,  it  is  more  desirable 
to  make  use  of  subprograms  or  libraries  developed  in  some  other  language  from  inside  Ada 
programs  without  having  to  translate  everything  into  Ada.  For  a  complete  Ada  interface  to 
another  language,  the  following  six  steps  are  necessary 

•  Create  Ada  data  types. 

•  Interface  to  external  routines. 

•  Interface  to  external  data. 

•  Link  to  external  libraries. 

•  Test/debug  the  interface. 

•  Optimize  the  interface. 

The  MICROSTICK  is  a  professional  high  quality  point  and  select  device.  The  de¬ 
vice  allows  users  to  change  gears  and  use  the  MICROSTICK  for  both  high-resolution  accu¬ 
racy  and  fast  pointing  speed.  Connecting  is  done  through  a  25-pin  RS232  connector.  The 
MICROSTICK  outputs  an  18  byte  string  of  ASCII  characters.  Software  controlling  the 
MICROSTICK  will  be  used  in  this  research. 


III.  Analysis! Design 

3.1  Introduction 

This  chapter  describes  the  analysis  and  design  phase  of  this  thesis  work.  The  previous 
research  efforts  by  other  AFIT  students  have  generated  many  objects.  Each  of  the  objects 
can  be  reused,  but  the  reuse  process  may  differ  depending  on  the  representation  of  each  of 
the  objects  and  on  the  effort  to  reuse.  This  chapter  is  concerned  with  derived  reuse  that  is 
accomplished  via  the  00  principle  of  classes/objects  and  their  relationships.  As  a  part  of 
this,  severed  ways  of  building  Ada  software  components  are  discussed.  The  discussion  will 
range  from  domain  analysis  and  component  identification  to  the  development  of  effective 
reusable  software  components  for  flight  simulator  applications.  The  concerns  are  the  char¬ 
acteristics  of  good  reusable  software  components,  such  as  maintainability,  understandability, 
e«ise  of  use,  the  importance  of  quality,  and  generality. 

When  building  a  reusable  software  component,  a  systematic  approach  to  identify  and 
to  develop  reusable  components  is  needed.  This  usually  comes  from  domain  analysis  that 
leads  to  the  identification  of  common  obje:ts,  operations,  and  structures.  Reusable  code 
components  are  designed  with  the  following  goals  in  mind; 

•  Reusability:  The  design  should  provide  for  reusing  existing  code  and  a  framework  that 
enables  the  reuse  of  new  code. 

•  Extensibility:  The  design  should  be  constructed  so  that  future  additions  to  the  design 
can  be  made  with  a  minimum  effort. 

•  Utility:  Design  of  each  component  should  Include  useful,  easy,  and  flexible  object 
functions. 

3.2  Analysis 

While  the  focus  of  this  thesis  is  the  design  and  implementation  of  a  reusable  component 
to  evaluate  the  features  of  Ada,  it  is  not  possible  to  simply  start  with  a  design.  The  analysis 
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should  be  done  first  in  order  to  have  a  starting  point  for  the  design.  Analysis  is  concerned 
with  devising  a  precise,  concise,  understandable,  and  correct  model  of  the  real  world.  An 
analysis  model  is  built  to  abstract  essential  aspects  of  the  application  domain  without  regard 
for  eventual  implementation.  This  model  contains  objects  found  in  the  application,  including 
a  description  of  the  properties  of  the  objects  and  their  behavior. 

As  a  part  of  the  analysis,  the  understanding  of  the  system  and  object  notations  used 
in  this  thesis  was  required.  This  came  from  Captain  Simpson’s  system  and  object  notations 
(.37).  The  analysis  started  with  domain  analysis  of  the  flight  simulator. 

A  domain  analysis  is  an  investigation  of  a  specific  domain  or  application  area  to  iden¬ 
tify  a  common  “generic  paradigm”  and  to  identify  candidate  reusable  components  for  the 
domain  (14:13).  A  domain  analysis  is  similar  to  a  system  analysis,  but  is  much  broader  in 
scope.  The  domain  analysis  results  in  development  of  a  domain  model  that  provides  the 
framework  for  development  of  reusable  software  components.  In  other  words,  it  leads  to  the 
identification  of  common  objects,  operations,  and  structures.  One  of  the  most  important 
things  in  performing  a  commonality  study  is  a  level  of  commonality,  which  is  captured  by 
means  of  abstraction/decomposition,  generalization/specialization  and  parameterization. 

There  are  several  techniques  that  can  be  used  in  performing  a  commonality  study.  One 
of  them  is  an  OOA  software  decomposition  technique  based  on  the  classes  of  objects,  which 
are  viewed  cis  a  “high-level  abstraction”,  as  in  an  ADT.  An  ADT  is  a  class  of  objects  defined 

by  a  set  of  operations  available  on  them  and  the  abstract  properties  of  these  operations. 

1 

An  OOA  of  the  domain  and  each  member  of  the  domain  representation  set  can  lead  to 
the  identification  of  commonality  across  ap])lications,  and  can  be  used  as  a  good  starting 

I 

point  for  the  development  of  a  domain  model  and  associated  reusable  software  components. 
A  class  in  an  object  model,  as  Booch  points  out,  is  a  set  of  objects  that  have  a  common 
structure  and  common  behavior.  The  object!  class  is  a  candidate  reusable  component  for 
the  domain.  Therefore  an  OOA  of  the  domaiii  can  serve  as  domain  analysis  for  building  a 
reusable  software  component. 
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The  main  purpose  of  the  andysis  phase  was  to  identify  potential  reusable  software 
components.  The  identification  of  reusable  components  was  based  mdnly  on  the  flight 
simulator  object  model  shown  in  Appendix  A  (37).  Several  base  classes  were  identified 
as  reusable  components,  then  the  low  level  inputs  (Joystick  and  RS232  Port  cleisses)  were 
selected  as  reusable  components  for  use  in  this  thesis.  The  Joystick  emd  RS232  port  are  not 
typical  graphics  components,  but  they  work  much  like  graphics  components.  The  system 
interface  to  control  the  I/O  devices  is  essentially  required  to  use  system  calls  written  in 
C  much  like  Graphics  Library  interfaces.  Hence,  software  components  controlling  the  low 
level  devices  such  as  I/O  and  Graphics  devices  are  good  candidates  for  reusable  software 
components,  and  they  .Illustrate  the  same  principles  as  we  would  find  in  building  reusable 
graphics  components. 


Figure  3.1.  Design  of  Joystick  and  RS232  Port  Classes 

■  ■  The  n^  step  was  to  analyze  the  joystick  class  and  the  115232  port  classes  and  their 
relationship  among  their  class  members  in  more  detail.  The  detailed  analysis  was  based 
mainly  upon  the  sources  available.  The  main  available  sources  of  information  for  analysis 
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were  the  user’s  manual  for  the  joystick,  previously  written  C++  routines,  and  the  object- 
oriented  model.  The  object-oriented  model  of  the  Joystick  and  RS232  port  objects  are  shown 
in  the  figure  3.1.  They  served  as  a  basic  domain  model  for  building  reusable  components  in 
this  thesis. 

The  joystick  communicates  with  the  computer  through  an  RS232  port.  The  RS232 
port  was  accessed  through  Unix  system  calls.  The  Joystick  used  both  the  Managed  RS232 
Port  and  the  Distributed  RS232  Port.  The  Distributed  RS232  Port  provides  a  transparent 
interface  with  another  machine  through  the  Unix  socket.  Since  both  the  Unmanaged  RS232 
Port  and  the  Distributed  RS232  Port  have  common  methods,  an  abstract  class  named  “Port” 
was  created.  The  “Disport”  object  is  the  “main”  program,  which  makes  and  runs  the  Port 
Reader.  The  Port  Manager  object  is  responsible  for  the  extra  checking  of  port  usage  on 
different  machines. 

The  next  step  was  to  identify  existing  code  that  could  be  reused  in  the  design  and 
implementation  in  order  to  reduce  the  overall  effort  required.  The  reused  code  came  from 
the  Unix  system  library  and  the  flight  simulator  class  library.  For  example,  the  Unix  system 
library  is  required  to  control  a  hardware  device.  But  reusable  code  was  written  in  C++ 
or  C  and  was  not  visible  directly  from  Ada.  For  a  successful  Ada  binding  to  C++  and 
C,  the  binding  feasibility  was  analyzed.  There  is  a  series  of  procedures  that  is  required  to 
successfully  develop  a  binding.  For  a  complete  Ada  binding  to  a  library  and  existing  code 
using  the  same  subprogram  and  variable  names  provided  in  the  original  C++  or  C  version, 
the  following  steps  are  necessary. 

•  Create  parallel  data  types. 

•  Interface  to  external  symbols  (routine  and  data). 

•  Link  to  external  libraries. 

Whenever  access  to  routines  or  variables  declared  in  an  alternative  language  is  required,  any 
Ada  variable  used  in  conjunction  with  the  subroutine  or  variable  is  compatible  with  the  C++ 
or  C  data  representation.  Once  these  parallel  types  have  been  established,  the  next  step  is 
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to  gain  access  to  external  routines  and  data  provided  in  the  interface  target  language.  This 
is  accomplished  in  a  two  stage  procedure:  first,  equivalent  Ada  subprogram  specifications 
are  written,  and  second,  the  linkage  to  the  external  routine  and  data  is  declared.  The  first 
step  can  be  a  simple  mapping  of  external  routine  and  data  names  and  parameters  into  an 
Ada  subprogram  specification.  The  second  step  is  accomplished  through  use  of  the  pragma 
INTERFACE  and  pragma  INTERFACE.N AME.  Linking  the  symbols  built  in  Ada  with  the 
external  C++  or  C  symbols  is  done  by  the  Ada  linker.  The  detailed  binding  process  is 
presented  in  chapter  2. 

For  each  class  object,  a  detailed  analysis  was  performed.  Basically,  the  Unman- 
aged_RS232  Port  class  was  a  wrapper  class  to  call  Unix  system  calls  to  control  an  RS232  port 
for  the  input  on  one  machine.  Captain  Simpson’s  code  was  instrumental  in  its  detailed  Unix 
system  calls  to  control  the  RS232  port  (37).  Using  Captain  Simpson’s  code  and  a  variety  of 
Unix  system  calls  (36),  all  information  necessary  for  analyzing  a  wrapper  class  was  obtained. 
The  primary  motivation  for  making  a  wrapper  class  is  to  make  library  or  operating  system 
routines  easier  to  use.  Thus,  only  the  file  descriptor  was  needed  oiice  the  RS232  Port  was 
opened.  Most  of  the  complexity  occurred  in  the  initialization  of  the  port.  Given  the  Unman- 
aged-RS232  Port,  this  work  shifted  into  how  to  reuse  existing  C  code  within  Ada.  Most  of 
the  Unix  system  calls  in  the  Unmanaged_RS232  Port  class  were  used  to  control  I/O  devices, 
and  some  had  complicated  data  structures.  Thus,  successful  development  of  a  binding  (in¬ 
terfacing)  to  Unix  system  calls  was  required.  Fortunately,  VADS  provided  the  ‘graphiclib’ 
and  ‘publiclib’  libraries  which  provide  ways  to  interface  with  Unix  system  calls  (41).  These 
libraries  provided  parallel  data  structures  between  Ada  and  C  corresponding  to  most  of  the 
system  calls  for  I/O  and  graphic  devices.  For  example,  the  lOCTL  system  call  was  needed 
to  represent  the  way  the  port  should  function,  such  as  enable  receiver,  enable  signals,  and 
enable  user  specified  baud  rate.  VADS  provided  exactly  the  same  data  representation  with 
it. 

Another  big  concern  with  Captain  Simpson’s  object  model  was  how  data  transfer 
occurred  between  two  computers.  However,  I  didn’t  analyze  it  in  much  detail  since  my 
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intention  was  to  reuse  it.  By  reuse  of  these  C++  routines,  features  of  Ada  and  the  C++ 
class  library  interface  can  be  evaluated. 

The  analysis  of  the  Joystick  class  proceeded  in  a  manner  similar  to  the  analysis  of  the 
R3232  port  class.  One  major  concern  with  the  Joystick  class  was  the  degree  of  concurrency. 
In  certain  modes,  the  joystick  would  operate  independently  of  the  computer.  In  addition, 
the  Unix  operating  system  was  capable  of  multiple  processes  running  at  the  same  time  in  a 
time  sharing  mode.  The  Unix  operating  system  input  routines  associated  with  the  joystick 
would  be  part  of  a  separate  process  from  the  one  ruiming  the  flight  simulator.  Identifying 
concurrency  in  the  analysis  phase  made  the  issue  of  concurrency  easier  to  handle  in  the 
implementation  phase  because  task  types  in  Ada  were  known. 

The  methods  and  attributes  needed  for  each  class  within  their  class  hierarchy  were 
analyzed.  The  main  concern  with  analyzing  methods  and  attributes  was  with  their  reuse. 
It  seemed  that  all  methods  providing  for  the  classes  were  methods  that  the  object  could 
provide  using  only  the  state  information  contained  within  it.  The  rest  of  the  classes  in  figure 
3.1  were  analyzed  in  a  similar  manner. 

3.3  Design 

The  design  of  a  software  system  is  one  of  the  most  important  parts  of  a  software 
development  effort.  The  analysis  weis  done  by  examining  the  relationships  between  the 
object-oriented  model  and  domain  model,  by  analyzing  Ada  bindings  tc  C++  and  C,  and  by 
analyzing  the  object-oriented  model.  The  design  decisions  were  then  made  and  details  added 
to  the  model  in  order  to  describe  and  optimize  the  implementation.  The  overall  idea  was  to 
produce  a  reusable  software  component  that  users  could  use  in  other  applications  without 
modification  or  with  providing  parameters.  The  main  goal  in  designing  and  implementing 
each  component  was  the  ease  of  use  and  reusability  (extensibility  and  maintainability  were 
derived  from  designing  for  reusability). 

Making  the  component  easy  to  use  for  the  designer  who  plans  to  use  the  interface  of  the 
component  is  centered  totally  upon  the  methods  that  are  offered  by  the  component.  When 
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used  in  this  manner,  the  component  can  be  viewed  as  a  “black  box”.  Information  hiding  and 
encapsulation  derived  from  abstraction  of  the  component  interface  is  the  overriding  principle 
in  making  components  easy  to  use. 

The  main  idea  to  build  reusable  software  component  was  to  look  at  the  software  com¬ 
ponent  from  the  perspective  of  a  potential  user  of  a  class.  All  components  were  constructed 
from  the  standpoint  that  they  may  be  used  in  other,  possibly  unrelated  applications.  One  of 
the  most  effective  ways  of  accomplishing  this  is  to  look  at  the  component  in  isolation  from 
the  rest  of  the  system  being  built. 

The  design  of  such  reusable  software  components  presents  the  design  with  a  set  of 
characteristics  of  reusable  components.  There  are  several  important  characteristics  of  com¬ 
ponents  intended  for  reuse  (18:84).  One  of  the  characteristics  of  reusable  components  is  a 
component’s  interface.  The  syntactic  interfaces  specify  compile-time  invariants  that  deter¬ 
mine  how  components  fit  together,  and  semantic  interfaces  specify  execution-time  invariants 
that  determine  what  the  component  computes.  Another  important  characteristic  of  reusable 
components  is  abstraction,  which  was  mentioned  in  the  previous  chapter  as  the  most  pow¬ 
erful  tool  available  to  the  human.  The  idea  of  function  abstraction  is  that  a  function  F  may 
be  specified  entirely  by  an  input  -  output  relationship.  The  user  of  a  component  based  on 
function  abstraction  need  not  know  how  the  function  is  implemented.  Another  important 
abstraction  technique  is  data  abstraction,  in  which  data  as  well  as  function  implementation 
may  be  hidden  from  the  user.  With  this  abstraction  technique  and  component’s  interface 
approach,  Ithe  hidden  data  characterizes  the  current  state,  which  may  be  transformed  by 
means  of  the  set  of  internal  (hidden)  operations.  However,  it  is  much  more  difficult  to  define 
how  one  should  go  about  designing  components  to  exhibit  these  properties. 

Components  that  incorporate  these  techniques  are  usually  referred  to  2is  objects  and 
are  said  to  be  object-oriented.  The  object  i?  a  reusable  software  component  having  a  hidden 
state  and  a  s^t  of  operations  or  capabilities  for  transforming  the  state.  OOD  has  been  widely 
accepted  as  being  a  method  which  is  likely  to  lead  to  substantially  increased  software  reuse, 
with  abstract  objects  being  perceived  as  the  natural  unit  of  reuse.  The  class  to  which  such 
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objects  belong  resemble  ADTs  in  many  ways.  ADT  is  a  class  of  objects  defined  by  a  set  of 
operations  available  on  them  and  the  abstract  properties  of  these  operations. 

OOD  promotes  reuse  by  means  of  interface  abstraction  -  use  of  the  interface  does  not 
require  knowledge  of  the  implementation,  and  inheritance  mechanisms  -  inheritance  is  a 
mechanism  for  deriving  one  abstraction  from  another,  specifying  only  the  difference  between 
the  new  (derived)  and  old  (parent).  This  inheritance  mechanism  establishes  a  relationship 
between  these  abstractions,  usually  a  dependency  of  the  derived  class  on  the  parent  with  the 
benefit  of  eliminating  the  need  to  recode  each  new  abstraction  form  scratch.  This  increases 
software  productivity  through  abstraction  reuse. 

The  design  of  the  reusable  Joystick  and  RS232  Port  components  was  not  considered  a 
main  effort  since  the  OOD  model  was  reused.  This  model  focused  on  r»- usability  with  C++. 
For  example,  “Unmanaged.RS232_Port”  and  “Distributed.RS232_Port”  were  inherited  from 
the  abstract  class  “Port”.  Given  this  relationship,  the  “Joystick”  instantiated  any  type  of 
“Port”  and  used  polymorphic  methods  to  use  any  type  of  Port  because  this  polymorphism 
was  provided  by  C++. 

However,  redesign  was  required  for  adapting  to  the  Ada  culture.  The  first  option  was  to 
make  each  Port  a  component  of  the  Joystick  since  Ada  does  net  support  run-time  polymor¬ 
phism.  In  addition,  two  more  modifications  were  performed.  The  “Managed_RS232_Port” 
was  not  inherited  from  “Unmanaged.RS232_Port”  because  it  acts  just  the  same  as  the  “Un- 
managed_RS232_Port”.  The  “Ada_wrapper”  for  wrapping  C++  routines  was  added  to  sur¬ 
round  the  C++  class  members  and  allow  them  to  be  gradually  replaced  later.  The  modified 
Joystick  and  RS232  Port  classes  OOD  model  is  depicted  in  figure  3.2. 

The  second  option  was  to  make  a  pointer  to  a  “Port”  class  object  a  component  of  the 
“Joystick”  class.  A  pointer  to  a  “Port”  class  object  is  now  a  component  of  the  “Joystick”. 
This  relationship  makes  “Joystick”  instantiate  any  type  of  “Port”  and  use  polymorphic 
methods  to  use  any  type  of  Port.  This  option  was  taken  because  it  provides  a  higher  abstract 
view  of  port  objects,  and  also,  Ada  9X  provides  run-time  polymorphism.  The  design  of  this 
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Figure  3.2.  Option  1:  Design  of  Joystick  and  RS232  Port  Classes 


modification  appears  in  figure  3.3.  The  detailed  design  of  the  Joystick  and  RS232  port  are 


shown  in  the  Appendix  A. 


Since  one  of  the  main  purposes  of  this  thesis  was  to  access  existing  C++/C  routines, 
the  design  of  the  joystick  and  RS232  Port  components  were  conceptually  separated  by  two 
subcomponents,  one  to  control  an  RS232  port  for  the  input  on  one  machine,  the  other  to 
control  an  RS232  port  for  getting  data  from  one  machine  to  the  other.  The  former  was 
intended  to  have  routines  written  in  Ada,  and  the  latter  was  intended  to  have  routines 
written  in  C++.  By  separating  components,  this  design  was  able  to  evaluate  the  features  of 
Ada  interfacing  with  a  C++  clcisses  library  through  the  “Ada. Wrapper”  class. 


3.3.1  Alternative  Methods  for  Design  of  a  Reusable  Component.  Several  methods 
for  building  a  well-engineered  reusable  component  were  considered.  Each  alternative  achieves 
the  goal  of  building  reusable  components  by  having  some  effect  on  00  mechanisms  with 
Ada  language  features,  such  as  generic  units  with  default  formal  parameters  (both  objects 


Figure  3.3.  Option  2;  Design  of  Joystick  and  RS232  Port  Classes 

and  subprograms),  strong  data  typing,  derived  types  and  subprograms,  and  subprogram 
overloading.  These  alternatives  address  not  only  to  a  limited  extent  all  the  fundamental 
features  of  the  object-oriented  paradigm  in  Ada,  but  also  the  conflicting  goals  that  arise  in 
the  design  of  reusable  software. 

3.3.2  Abstract  State  Machine  (ASM)  Approach.  The  most  direct  representation 
of  an  object  is  a  state  encapsulating  package  (termed  abstract  state  machine  approach) 
exporting  a  set  of  operations  that  can  be  used  to  access  and  update  the  object  state.  ASM 
is  a  kind  of  “black-box”  approach.  The  user  is  provided  with  a  high-level  interface  to  the 
components.  There  is  no  direct  access  to  the  data  structures  themselves.  All  access  is 
through  the  operations  provided  in  the  interface.  Using  generic  packages,  this  approach  can 
be  extended  to  emulate  a  class.  The  Unmanaged_RS232  port  object,  for  example,  can  be 
represented  explictly  in  Ada  as  an  ASM  package  of  form: 

with  port; 
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generic 

package  Unmanaged_RS232_Port  is 

function  Close_Port  (OB  :  in  object)  return  boolean; 
procedure  Flush-Queue  (OB  :  in  object)  ; 

package  body  Unmanaged-RS232_Port  is 
type  object  is  record 

port-number  :  port. port-numbers;  -  port  number  of  device  (minus  1) 
tty-type  :  tty.termio;  -  port  settings 

port-speed  :  unsigned-types. unsigned-short-integer;  -  port  speed  setting 


end  record; 


A  generic  state-encapsulating  package  with  this  interface  defines  an  object  template 
from  which  multiple  structurally  identical  instances  can  be  generated.  However,  generic 
packages  are  static  entities  that  can  only  be  instantiated  at  compile  time,  and  thus  do  not 
support  the  concept  of  dynamically  instantiatable  objects  identified  by  references,  let  alone 
support  the  accompanying  mechanisms  of  inheritance,  polymorphism  and  dynamic  binding. 

3.3.3  Task  Approach.  The  second  method  is  to  represent  objects  as  tasks.  This 
method  can  support  dynamically  instantiatable  classes  and  the  notion  of  concurrency.  It 
can  also  be  used  to  realize  a  form  of  dynamic  binding.  In  this  approach  the  class  Joystick 
can  be  represented  by  a  task  type  of  the  form:  _ 

tcisk  type  Joystick  is 

entry  get-coordinates(x-value  ;  in  out  integer;  _ 

y-value  :  in  out  integer; 
butl  :  in  out  integer; 
but2  :  in  out  integer; 
but3  :  in  out  integer; 
flag  :  in  out  boolean); 

entry  Set-Joystick_Mode(new-mode  :  in  joystick-mode); 


3-11 


One  of  the  main  advantages  of  this  approach  is  that  it  supports  the  notion  of  concur¬ 
rency  and  enables  objects  to  be  active.  It  can  also  be  used  to  realize  a  form  of  dynamic 
binding  because  Ada  permits  a  task  to  define  several  different  ‘accept  ’  statements  (method 
bodies)  for  each  entry  (method)  exported  in  the  interface.  By  parameterizing  the  task  with 
a  flag  indicating  which  of  the  ‘accept  ’  statements  is  to  be  executed,  it  is  possible  for  dif¬ 
ferent  instances  of  a  single  task  type  to  provide  alternative  implementations  for  the  entry 
concerned.  However,  the  problem  with  this  method  is  that  classes  emulated  by  task  types 
in  Ada  can  not  provide  support  for  inheritance.  Another  problem  is  that  they  can  not  be 
library  units  (5:184-185). 

3.3.4  ADT  Approach.  In  addition  to  the  above  two  approaches,  the  nojtion  of  ADT 
can  be  used  for  representing  objects  and  classes.  In  this  method,  an  object  is  defined  by  a 
package  exporting  an  ADT.  The  data  structure  is  declared  in  the  private  section  in  a  package 

specification,  thus  the  user  is  “stuck”  with  the  data  structure  provided  by  the  designer.  To 

i 

change  it,  he  must  change  both  the  specification  where  the  data  structure  is  defined  and 
the  body.  This  approach  differs  from  the  ASM  approach  in  that  the  interface  consists  of 

I 

both  the  predefined  set  of  operations  and  the  data  structure  itself,  but  the  state  of  the  data 

I 

is  not  captured  (14:45).  The  package  exporting  the  type  and  associated  methods  does  not 

itself  represent  an  object  but  rather  variables  of  the  exported  data  type,  and  the  package 

t 

defining  the  ADT  corresponds  more  to  a  class,  therefore,  than  to  an  object.  The  reference 
semantics  and  the  dynamically  instantiated  objects  are  provided  by  making  the  exported 
type  an  access  type  rather  than  a  static  type.  The  main  advantage  of  this  method  is  that 
it  provides  limited  support  for  two  important  mechanisms  associated  with  classes/objects, 
inheritance  and  polymorphism  through  the  variant  and  class-wide  programming.  This  can 
provide  a  representation  of  inheritance  with  respect  to  the  operations  associated  with  a  class. 
The  following  example  shows  how  the  use  of  this  can  implement  inheritance. 

Package  Port  is 

Type  Port.Type  is  (Unmanaged-RS232_Port_Type,  Distributed_RS232_Port_Type) 
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-declare  the  variant  record. 

Type  Port-Record  is  private; 
type  Port  is  access  Port -Record; 
subtype  Unmanaged-RS232-Port  is  Port; 
subtype  Distributed-RS232-Port  is  Port; 

function  Unmanaged-Port-Open(Self  :  Unmanaged_RS232-Port)  return  boolean; 
function  Distributed-Port_Open(Self  :  Distributed-RS232_Port)  return  boolean; 
function  Port-Open(Self  ;  Port-Type)  return  boolean; 


private 

Type  Port-Record  (Class  :  Port-Type)  is 
record 

Port-Open  :  Boolean; 
case  Class  is 

when  Unmanaged_RS232-Port-Type 
Port-FD  :  integer; 

Port-Speed  :  integer; 


when  Distributed-RS232_Port-Type 
Data-Socket  :  Socket; 
Cmd-Socket  :  Socket; 

end  Ccise; 
end  record; 
end  Port; 


However,  the  main  shortcoming  of  the  derived  type  and  subtype  mechanisms  is  that 
they  do  not  permit  the  set  of  state  variables  associated  with  an  abstraction  to  be  extended. 
Building  a  new  system  from  pre-existing  components  is  not  possible  without  modification 
or  adaptation  to  the  specific  requirements  of  the  new  system  to  fully  facilitate  reuse.  For 
example,  the  record  type  with  variant  part  is  used  to  model  Port-Record.  The  actual  struc¬ 
ture  and  processing  depends  on  their  Port-Type,  which  is  used  as  a  discriminant.  How¬ 
ever  there  are  several  problems  with  this  approach.  For  example,  wherever  code  exists  to 
handle  Port-Record,  case  statements  must  be  used  to  determine  the  actual  subtype  of  the 
Port-Record  prior  to  its  processing.  For  example,  the  following  program  shows  how  the 
actual  subtype  is  determined. 
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function  Port.Open  (Self  :  Port-Type)  return  boolean  is 
begin 

case  self.  Class  is 

when  Unmanaged_RS232.Port_Type  =» 
return  Unmanaged_Port.Open(Self); 
when  Distributed-RS232_Port_Type  ^ 
return  Distributed_Port_Open(Self); 
when  others  =^>  return  false; 
end  case; 
end 


This  variant  approach  is  fragile  in  maintenance.  For  example,  if  a  programmer  wants  to 
modify  the  system  to  support  a  new  Port-Type  (e.g.,  y.21_type),  then  type  Port-Type  must 
be  modified,  as  must  type  Port-Record,  as  well  as  any  subprograms  that  handle  Port-Type  or 
Port-Record,  even  if  these  operations  do  not  require  any  additional  logic  for  the  X.21-type.  ^ 

5.5.5  Generic  Approach.  Another  method  for  representing  classes  and  objects  is  to  ' 

use  Ada  generic  units  to  provide  components  which  are  tailorable  to  user-defined  types.  It 
provides  flexibility  while  simplifying  use.  Types  and  operations  on  the  types  are  defined,  and 
the  types  can  then  be  used  to  instantiate  the  generics  and  the  operations  will  get  pulled  along. 

The  major  advantage  of  this  approach  is  that  it  incorporates  strong  typing  and  is  flexible. 

However,  the  user  would  need  to  supply  a  large  number  of  generic  parameters.  This  burden 
can  be  alleviated  by  the  judicious  use  of  default  parameters.  Generics  can  be  exploited  in 
the  development  of  reusable  components.  Low-level  components  can  be  designed  as  generic 

packages  or  subprograms.  A  set  of  higher-level  parts  components  can  then  be  built  from  / 

multiple  levels  of  these  generic  units.  The  user  provides  actual  parameters  to  instantiate 

y 

the  generic  components  and  tailor  them  to  his  application.  This  approach  would  be  used 
with  the  ASM  or  ADT  approach.  Effective  use  of  generic  units  for  the  creation  of  reusable 
components  requires  reconciliation  between  the  complexity  of  the  generic  specification  and 

the  ecise  of  use  of  the  component.  ^ 
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S.3.6  Using  Ada  9X.  Ada  9X  allows  ADTs  to  have  user-defined  initialization  and 
fin2ilization  and  generalizes  user-defined  equality /inequality  for  any  type.  Ada  9X  also  adds 
class-wide  operations  as  well  as  run-time  polymorphism  within  a  class  of  related  types  as  an 
option  for  programmers,  while  retaining  Ada’s  generally  static  type  model. 

Ada  9X  provides  support  for  the  paradigm  of  object-oriented  programming  (OOP) 
through  powerful  mechanisms  for  variant  and  class- wide  programming  and  child  library 
units.  For  example,  the  limitations  of  the  Ada  83  ADT  approach  can  be  addressed  with  Ada 
9X.  With  Ada  9X,  the  programmer  can  use  tagged  type  extension  and  subprogram  dispatch 
to  simplify  the  system,  handling  each  variant  as  a  derived  type  extension,  eliminating  variant 
records  and  case  statements.  Processing  for  each  kind  of  Port-Record  is  localized  to  a  type, 
and  dispatch  will  insure  that  the  proper  operation  is  called  for  in  each  instance.  For  example, 
the  above  Ada  83  code  will  be  translated  into  Ada  9X  code  as  follows: 

Package  Port  is 

type  Port  is  tagged  private; 

function  Port_Open(Self  :  Port)  return  boolean; 

type  Unmanaged_RS232_Port  is  new  Port  with  private; 
function  Port_Open(Self  :  Unmanaged_RS232_Port)  return  boolean; 
type  Distributed_RS232-Port  is  new  Port  with  private; 
function  Port_Open(Self  :  Distributed_RS232_Port)  return  boolean; 


private 

type  Port  is  tagged; 
record 

Port-Open  :  Boolean; 
end  record; 

end  Port; 


Now  the  variant  record  type  has  been  replaced  with  a  Port  and  two  types  derived  from 
it.  Type  Unmanaged_RS232-Port  extends  the  Port  and  has  its  own  Port-Open  function. 
Each  derived  type  inherited  the  primitive  operation  of  its  parent  type  Port.  Each  derived 
type  has  its  own  Port-Open  procedure,  and  overrides  function  Port-Open  of  the  parent 
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function  Port.Open.  In  addition,  the  new  type  can  contain  additional  components,  and 
one  can  define  new  operations.  Instead  of  the  single  function  Port.Open  embodying  a  case 
statement  as  in  the  Ada  83  solution,  the  Ada  9X  solution  distributes  the  logic  for  handling 
Port-Record  to  each  specific  Port-Type,  without  redundancy. 

function  Port.Open(Self  :  Port)  return  boolean  is 
begin 


end 

function  Port.Open(Self  :  Unmanaged_RS232-Port)  return  boolean; 
begin 

Port-Open(  Port  ( self ) ) ; 

end 

Each  body  for  Port.Open  encloses  just  the  code  relevant  to  the  type,  and  delegates 
additional  processing  to  an  ancestor  via  an  explicit  type  conversion.  In  Ada  9X,  view  conver¬ 
sions  to  a  tagged  cl^lss-wide  type  preserve  the  tag  of  the  object  to  permit  repeated  dispatch 
within  the  class  determined  by  the  target  type. 

If  a  new  kind  of  Port.Type  for  special  purpose  must  be  added,  it  may  be  done  without 
disturbance  or  recompilation  of  the  existing  system  code  as  a  separate  package.  The  following 
example  program  shows  how  a  new  variant  can  be  added. 

with  Port; 

package  Port.New_Port  is 

type  X.21_port  is  new  port. port  with  private; 
function  Port-Open(Self  :  X.21.Port)  return  boolean; 

However,  objects  of  Port ’class  are  of  unknown,  varying  size,  due  to  the  possibility  of 
extensions.  For  the  Port,  the  set  of  values  of  the  class- wide  type  Port ’class  is  the  union  of 
the  set  of  values  of  Port  and  all  of  its  derivatives.  For  this  reason,  Ada  9X  treats  them 
as  unconstrained,  analogous  to  unconstrained  array  types  (e.g.,  string)  in  Ada  83  (1).  For 
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example,  when  a  class- wide  type,  Port ’class,  appears  as  the  designated  type  in  an  access 
type  declaration,  the  resulting  type  may  designate  any  object  within  the  class  rooted  at 
Port.  Using  such  cleiss-wide  access  types  will  be  a  common  idiom  of  OOP  in  Ada  9X.  For 
example,  the  following  code  will  be  inserted  in  package  Port: 

type  Port-ptr  is  access  Port’class; 

function  Port_Open(class_Ptr  :  Port_Ptr)  return  boolean; 

Port-ptr  is  an  access  type  with  designated  type  Port’Class.  This  allow  Port_ptr  values 
to  designate  objects  of  type  Port,  or  any  derivative  of  Port.  The  operation  Open.Port  is 

■.  .  .  i 

a  class-wide  operation  in  that  it  takes  parameters  of  type  Port.ptr,  which  designates  the 
class-wide  type  Port’Class,  When  a  primitive  Lperation  of  a  tagged  type  is  called  with  an 
operand  of  the  class-wide  type,  the  operation  to  be  executed  is  selected  at  run-time  based 
on  the  type  tag  of  the  operand.  This  run-tim!e  selection  is  called  a  dispatching  operation. 

I 

Dispatching  provides  Ada  programmers  with  a  natural  unit  form  of  run-time  polymorphism 
within  classes  of  related  (derived)  types.  This  variety  of  polymorphism  is  known  as  “inclusion 
polymorphism”. 

Class-wide  programming  and  type  extension,  in  conjunction  with  generic  units,  pro¬ 
vides  many  useful  facilities.  Generic  units  may  be  parameterized  by  user-defined  classes, 
allowing  abstractions  to  be  built  around  such  classes.  Consider  the  following  example  pro¬ 
grams  in  conjunction  with  Port.  The  generic  package  Joystick  has  the  following  form: 

with  Port; 
generic 

type  generic_Port(<>)  is  new  port. port; 

with  function  Port.Open(self  :  generic_Port)  return  boolean; 


package  Joystick  is 


In  this  example,  type  generic. Port  will  be  matched  by  any  type  derived  Trom  port. port. 
This  generic  package  could  be  instantiated  with  a  specific  derivative  of  port.port  and  other 
actual  parameters.  The  notation  (<>)  specifies  that  the  actual  generic_Port  type  may  have 
any  number  of  discriminants  or  be  a  class-wide  type.  A  generic  unit  may  extend  a  tagged 
type,  adding  components  and  operations.  The  extended  types  declared  within  such  generic 
units  inherit  all  the  properties  of  the  original  type  and  process  all  the  new  properties  defined 
by  the  generic  units.  Such  generic  units  act  as  “mixin”  classes  and  provide  one  aspect  of 
multiple  inheritance  (1). 

Now  all  00  programming  mechanisms  were  provided.  The  only  debate  for  Ada  9X  is 
multiple  inheritance.  Ada  9X  supports  multiple-inheritance  via  multiple  with  fuse  clauses, 
via  private  extensions  and  record  composition,  via  the  use  of  generics  and  formal  packages, 
and  via  access  discriminants  (39).  However,  in  Ada  9X,  the  linguistic  multiple  inheritance 
mechanism  is  not  provided  because  of  the  potential  for  distributed  overhead  caused  by  mul¬ 
tiple  inheritance.  But  this  is  a  minor  point:  multiple  inheritance  is  a  programming  style,  not 
a  universal  tool,  and  object-oriented  practice  of  the  past  ten  years  indicates  that  the  critical 
benefit  of  OOP,  namely  code  reuse,  is  not  substantially  enhanced  by  multiple  inheritance 
(33). 

3.3.7  Abstract  Data  Type  with  Common  Class.  Using  these  different  methods,  it 
was  possible  to  achieve  something  of  the  effect  of  all  the  principal  object-oriented  mech¬ 
anisms.  None  of  these  methods  except  Ada  9X  is  acceptable  for  implementing  a  general 
object-oriented  language  like  C-f--k  because  they  each  support  only  a  certain  subset  of  the 
required  properties.  For  example,  if  a  class  is  modelled  by  a  task,  so  as  to  take  advantage  of 
the  dynamic  binding  and  concurrency,  it  is  not  possible  to  use  inheritance.  If  the  ADT  ap¬ 
proach  with  derived  types  and  subtypes  is  used,  it  does  not  permit  the  set  of  state  variables 
associated  with  an  abstraction  to  be  extended.  Ada  9X  is  the  best  solution  to  implementing 
a  set  of  reusable  components,  since  it  provides  support  for  the  paradigm  of  object-oriented 
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programming  (OOP)  through  powerful  mechanisms  for  variant  and  class-wide  programming 
and  child  library  units.  However  Ada  9X  was  not  available  at  the  time  of  this  work. 

Thus,  this  thesis  design  was  implemented  with  Ada  83.  The  next  solution  was  the  ADT 
approach.  The  final  alternative  was  the  ADT  approach  with  a  common  class  method.  This 
method  eliminates  limitations  such  as  type  incompatibility  with  the  simple  ADT  approach. 
ADT  with  the  common  class  method  was  the  approach  developed  and  used  on  the  DRA¬ 
GOON  project  (5).  The  main  difference  between  ADT  with  common  class  and  the  simple 
ADT  approach  is  that  the  state  of  object  is  not  represented  by  a  single  record  but  by  a  linked 
list  of  records.  Each  node  in  the  list  stores  the  state  variables  added  by  its  ancestors.  Thus 
the  state  of  the  objects  in  this  thesis  would  be  represented  by  a  list  with  the  ‘node’  storing 
their  attributes  specific  to  their  objects  added  to  a  ‘node’  storing  their  attributes  belonging 
to  their  classes  object.s.  Conceptually,  all  user-defined  application  classes  except  classes  for 
getting  data  from  one  machine  to  the  other  are  descendants  of  common.objtct  and  may  be 
assigned  to  instance  variables  of  this  class.  Therefore,  logically,  the  first  node  of  every  such 
state  list  corresponds  to  an  instance  of  the  class  cotnmon.object.  Figure  3.4  shows  the  full 
version  the  Joystick  and  RS232  port  class  hierarchy. 

In  ADT  with  a  common.object  class  approach,  all  objects  in  the  component  are  repre¬ 
sented  by  state  lists  whose  first  node  is  a  record  of  type  Common.Object.State,  referenced  by 
an  access  variable  of  type  Common.Object.Object.  Instances  of  class  Common.Object. Object 
are  a  special  case  in  that  their  state  is  represented  by  a  ‘uninode’  list  containing  a  single 
record  of  this  type.  The  Ada  record  type  used  to  generate  this  special  first  node  in  the  state 
list  is  defined  following  a  package  part  of  the  predefined  environment  of  every  Ada  library 
used  for  implementing  components  in  this  thesis. 

package  commonjobject  is 
type  state; 

type  object  is  access  state; 
type  state  is  record 

offspring.no  :  natural  :=  0; 
self ;  object; 
multiple  :  object; 
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Figure  3.4.  Full  Version  of  the  Joystick  and  RS232  Port  Class  Hierarchy 

heir  :  object; 
end  record; 

function  CREATE  (offspring.no  :  in  natural  :=  0) 
return  object; 
end  common-object; 


package  body  common-object  is 

function  CREATE  (offspring.no  :  in  natural  :=  0) 
return  object  is 
OB  :  object; 
begin 

OB  :=  new  state; 

OB.offspring_no  :=  offspring.no; 
OB. self  :=  OB; 

OB. multiple  :=  null; 


/ 
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end; 

end  common_object; 


OB.heir  ;=  null; 
return  OB; 


The  state  lists  corresponding  to  descendants  of  Common.Object. Object  are  composed 
of  an  Common.Object.State  record  followed  by  records  holding  the  state  variable  introduced 
by  each  of  the  classes  in  the  inheritance  chain.  This  is  the  basic  strategy  for  overcoming  the 
incompatibility  of  the  polymorphism  features  and  Ada’s  strong  typing  mechanism.  Since  the 
first  node  of  every  state  list  is  of  the  type  Common.Object.State,  all  objects  in  the  component 
eire  referenced  by  access  values  of  the  same  Ada  type  -  Common.Object.Object. 


The  OFFSPRING.no  and  MULTIPLE  fields  of  the  Common.Ob ject. State  ure  used  to 
handle  multiple  offspring  and  multiple  inheritance  situations,  respectively.  The  field  SELF, 
on  the  other  hand,  simply  points  back  to  the  record  so  that  objects  may  access  its  own  state. 
The  last  field  HEIR  is  the  one  that  contains  the  ‘links’  or  ref-jrences  to  other  nodes  to  build 


a  linked  list  for  non-trivial  objects.  In  the  case  of  instances  of  the  class  Common.Object,  the 
HEIR  field  is  left  containing  the  value  ‘nu//’ since  the  ‘state*  of  each  objects  is  represented  by 
an  instance  of  Common.Cbject.State  alone.  However,  for  objects  of  descendent  classes,  this 
field  is  used  to  point  to  the  next  node  in  the  list.  The  HEIR  field  of  the  Common.Object. State 
is  defined  to  be  any  type  OBJECT  for  convenience,  but  in  fact  any  access  type  would  have 


sufficed  because  it  is  impossible  to  predict  at  the  time  of  its  definition  what  the  type  of  the 
next  node  will  be.  This  information  is  only  available  when  an  heir  of  CommoVobject  is 
transformed.  This  is  the  point  at  which  the  Ada  typing  rules  need  to  be  broken  so  that  the 
nodes  representing  newly  defined  heir  classes  can  be  ‘linked’  on  to  the  list  correspLnding  to 
objects  of  the  parent  class.  To  make  this  HEIR  field  point  to  a  record  with  a  different  type 
to  Common.Object. Object,  Ada’s  predefined  generic  function  UNCHECKED.CONVERSION 
must  be  used  to  change  its  apparent  type. 

The  only  problem  with  this  approach  is  that  it  introduces  unnecessary  Common.Object 


cl£iss  and  attributes  for  making  each  class  linked.  For  example,  all  classes  are  inherited  from 
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Common.Object  class,  and  have  two  additional  attribul ’s  -  Offspring.no  and  Heir  which  are 
not  essential  to  them. 
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IV.  Detailed  Design  and  Implementation 

4.}  Introduction 

One  of  the  main  goals  of  this  thesis  was  that  C++  should  be  readily  translatable 
into  Ada  and  be  able  to  interface  with  Ada  for  building  reusable  software  components.  This 
chapter  describes  how  the  object  model  is  translated  into  Ada  in  a  fairly  succinct  and  natural 
style. 

4.2  Detailed  Design  and  Implementation  of  the  Reusable  Port  and  Unmanaged.RS2S2.Poii 
Component 

The  abstract  class  PORT  was  translated  into  a  package  with  the  following  specification 
and  body.  The  strategy  for  representing  PORT  objects  in  Ada  was  based  on  the  approach 
of  an  ADT  with  a  Common.Object  class.  The  PORT  objects  are  generated  by  the  member 
function  CREATE.  The  PORT  class  package  provides  the  reference  semantics  and  the  as¬ 
sociated  facility  for  dynamically  generating  objects  by  making  the  exported  type  an  access 
type  rather  than  a  static  type: 

with  commonjobject; 
with  unchecked-conversion; 
package  Port  is 

type  variable; 

type  state  is  access  variable; 
type  variable  is  record 

port-open  :  boolean;  -flags  if  port  is  open 
offspring.no  :  natural  :=  0; 

HEIR  :  commoiijobject.object; 
end  record; 

function  common-view.of  is  new 

unchecked-conversion  (source  port.state, 

target  commonjobject.object); 
function  port-view-of  is  new 

unchecked-conversion  (source  common-object.object, 
target  =»  port.state); 

function  part-of  (OB  :  in  commonjobject.object)  return  state; 
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function  create  (ofFspring.no  :  in  natural  :=  0)  return  commonjobject.object; 
function  Get.Port.Open  (OB  :  in  common_object. object)  return  boolean; 
function  Open.Port  (OB  :  in  common_object. object)  return  boolean; 
procedure  Read_From-Port( 

OB  :  in  common_object .object; 

Buffer  :  in  out  string; 
num_chars_to.read  :  in  integer; 
count  :  out  integer); 

..  -other  methods 
exception  :  UNDER-FLOW; 
end  port; 

Package  body  Port  is 

.  other  variables  and  functions 
function  create  (offspring.no  :  in  natural  :=  0) 
return  common_object.object  is 
com_obj  :  common.object.object; 
port-obj  :  state; 
begin 

port.obj  :=  new  variable; 
port_obj.ofFspring.no  :=  offspring.no; 
port.obj. HEIR  :=  null; 
com.obj  :=  commonjobject.create(l); 
com_obj.HEIR  :=  common-view_of(port_obj); 
return  com.obj; 

end; 

As  illustrated  in  figure  4.1  and  program  examples,  the  state  of  Port  object  is  rep¬ 
resented  by  a  linked  list  with  two  nodes,  the  first  node  of  type  Common.Object. State  and 
the  second  of  type  Port,  variable,  storing  port  attributes.  The  job  of  linking  the  two  nodes 
together  transparen^V  is  performed  by  the  CREATE  function  using  Ada’s  predefined  func¬ 
tion  UNCHECKED.CONVERSION.  To  enable  the  HEIR  field  of  the  first  node  to  point  to  a 
record  of  type  port,  variables,  the  create  function  makes  references  of  type  port. state  appear  to 
be  of  the  expected  type  Common.Object.  Object.  For  example,  the  porLview.oflnnct'ion  in  the 
example  program  is  an  instantiation  of  the  generic  function  UNCHECKED.CONVERSION 
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converting  access  values  of  type  port.state  to  the  type  Common.Object.  Therefore,  all  objects 
in  the  components  are  of  type  Common.Object.State  referenced  by  an  access  variable  of  type 
Common.Object. Object.  Not  only  does  this  mechanism  solve  the  problem  of  polymorphism, 
but  it  also  means  that  there  are  no  typing  obstacles  to  the  incremental  introduction  of  new 
subclasses,  since  instances  of  these  are  also  represented  by  state  lists  referenced  by  the  ac¬ 
cessed  variable  of  type  Common.Object. Object.  For  example,  if  the  HEIR  field  of  the  first 
node  is  ‘null’,  the  list  represents  an  instance  of  class  Common.Object,  if  not,  then  it  must 
correspond  to  a  descendant  of  Common.Object,  and  therefore  can  be  supplied  as  a  parameter 
to  a  method  of  a  descendant  class.  In  order  for  the  ‘methods’  of  the  class  to  manipulate  the 
state  variable  stored  in  the  corresponding  state  node,  the  Part.Of  function  was  introduced'. 
It  performs  the  inverse  ‘UNCHECKED.CONVERSION’  to  the  CREATE  function.  Given 
a  reference  of  type  Common.Object. Object,  it  returns  a  reference  of  the  access  type  defined 
in  its  package.  The  breaking  of  the  type  rules  is  therefore  performed  transparently  in  a 
disciplined  manner  through  the  two  functions  CREATE  and  PART.OF  within  each  package. 


4.2.1  Inheritance.  As  mentioned  previously,  the  inheritance  mechanism  supports 
the  reuse  of  an  existing  ADT  as  ti  e  basis  for  the  definition  of  the  new  ADT.  This  mech¬ 
anism  does  not  establish  any  connection  between  the  old  one  and  new  one.  In  this  thesis, 
this  inheritance  is  accomplished  through  the  linked  list,  which  has  a  common  object  access 
type.  In  a  linear  inheritance  hierarchy,  the  process  of  adding  nodes  onto  the  list  is  repeated 
for  each  new  addition  to  the  hierarchy.  As  illustrated  in  Figure  4.2,  the  state  of  a  Unman- 
aged.RS232.Port  object  is  stored  as  a  linked  list  of  three  nodes.  The  Ada  package  into  which 
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Unmanaged.RS232.Port  is  translated,  however,  is  completely  independent  of  the  record  types 
used  to  generate  the  first  two  nodes  in  the  list.  For  example,  Unmanaged.RS232.Port  would 
be  translated  into  a  package  of  the  form: 

with  port;  with  commonjobject; . 

package  Unmanaged_RS232-Port  is 
type  variable; 

type  state  is  access  variable; 
type  variable  is  record 

port.FD  :  os.files. file-descriptor;  -  port  file  descriptor  number 
port.type  :  port.port.comm-type;  -  terminal,  modem  or  flow  control 

ofFspring.no  :  natural  :=  0; 

HEIR  :  cornmon-object-object; 
end  record; 


function  part.of  (OB  ;  in  common_object.object)  return  state; 
function  create.of  ( 

port.num  :  in  port.port.numbers; 
speed  :  in  port.port_speed.spec; 
mode  :  in  port.port-input_mode; 
port-C-type  :  in  port.port.comm-type; 
offspring-no  :  in  natural  :=  0) 
return  common-object. object; 

...  other  functions 

function  Close-Port  (OB  ;  in  commonjobject.object)  return  boolean; 
procedure  Flush-Queue  (OB  :  in  common_object.object)  ; 


This  structure  is  not  affected  in  any  way  by  that  of  the  package  Port  corresponding 
to  its  parent  class.  The  only  place  in  which  reference  is  made  to  this  package  is  in  the 
implementation  of  the  Create  and  Part.Of.  The  Create  and  Part.Of  functions  would  be 
translated  into  a  function  of  form: 

package  body  Unmanaged-RS232_Port  is 

function  part.of  (OB  :  in  common_object.object)  return  state  is 
begin 

return  Unmanaged-RS232_Port_view_of(port.part_of(OB).HEIR); 
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end; 

function  create.of  ( 

port_num  :  in  port.port_numbers; 


ofFspring-no  ;  in  natural  :=  0)  return  common-object  .object; 
com-object  :  common-object  .object; 
rs232port  :  Unmanaged-RS232-Port.state; 
begin 

rs232port  :=  new  Unmanaged_RS232-Port.variable; 
rs232port  .offspring-no  :  =  offspring-no; 
rs232port.HEIR  :=  null; 

rs232port. port-mode  :=  mode; 
rs232port. port-type  ;=  port-C-type; 
com-object  :=  port.create(l); 

port.part_of(com-object).HEIR  :=  common-view-of(rs232port); 
return  com-object; 
end  Create-of; 


The  key  benefit  of  this  mechanism  is  in  the  structure  of  these  two  functions.  Redefining 
an  abstraction  from  a  pre-existing  class  is  not  at  all  influenced  by  the  implementation  of  the 
parent  class. 

4.2.2  Dynamic  Binding.  To  illustrate  the  problems  involved  in  implementing  this 
mechanism,  consider  the  class  Unmanaged.RS232.Port.  The  most  important  feature  of  this 
clciss,  as  far  as  dynamic  binding  is  concerned,  is  that  it  re-implements  some  of  the  methods 
inherited  from  abstract  class  PORT.  Consequently,  when  one  of  the  redefined  methods  is 
invoked  through  an  instance  variable  of  class  PORT,  the  particular  version  of  the  method 
which  is  executed  depends  on  the  dynamic  type  of  the  instance  variable,  that  is,  the  type 
of  the  object  to  which  it  is  referring  at  the  time  of  the  call.  The  problem,  therefore,  is  to 
decide  at  run-time  which  of  the  Ada  subprograms  implementing  the  alternative  versions  of 
the  method  should  be  executed.  Moreover,  the  incremental  development  facilities  of  the  00 
approach  mean  that  the  programmer  may  define  further  subclasses  at  any  later  stage;  the 
range  of  different  versions  that  may  be  invoked  does  not  remain  fixed.  There  must  be  some 
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Figure  4.2.  List  Structure  Holding  State  of  Unmanaged_RS232.Port  Objects 

Ada  code  in  the  system  that  knows  about  all  the  different  current  versions  of  a  method  in 
the  system  and  is  able  to  select  the  appropriate  version  at  run-time.  If  this  was  embedded 
in  the  body  of  the  Ada  packages  into  which  classes  are  translated,  however,  the  code  would 
have  to  be  reproduced  and  recompiled  each  time  a  new  version  of  a  method  was  defined  in  a 
subclass.  The  incremental  development  principle  of  the  00  approach  would  thus  be  largely 
undermined. 

Ada’s  features  for  defining'the  bodies  of  methods  in  physically  separate  subunits,  how¬ 
ever,  provides  an  elegant  mecha'pism  for  avoiding  this  problem.  It  permits  the  amount  of 
code  that  has  to  be  updated  to  cater  to  the  introduction  of  new  method  versions  to  be  limited 
to  a  single  procedure  body.  None^of  the  subprograms  declared  in  the  package  specification 
actually  implements  the  correspoiiding  method  directly,  however.  This  job  is,  in  fact,  per¬ 
formed  by  an  additional  set  of  mejhods  declared  in  a  package  SELF  contained  in  the  body 
of  the  main  package.  The  bodies  of  the  visible  subprograms  declared  in  the  specification  of 
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the  main  package  are  contained  in  ‘separate  ’  units  and  use  the  subprograms  defined  in  the 
inner  package  SELF  to  implement  the  original  method. 

Package  body  Port  is 
package  self  is 

function  Open_Port  (OB  :  in  common jobject.object)  return  boolean; 
procedure  Read-From_Port( 

OB  :  in  common  jobject.object; 

Buffer  :  in  out  string; 
num_chars_to_read  :  in  integer; 
count  :  out  integer); 


end  self; 

package  body  self  is 

function  Open-Port  (OB  :  in  commonjobjeot.object)  return  boolean  is 
begin 

if  port.part.of(OB)  =  null  then 

raise  UNDER_FLOW; 

else 

return  false; 
end  if; 
end; 

procedure  Read-From_Port( 

OB  :  in  commonjobject.object; 

Buffer  :  in  out  string; 
num_chars_to-read  :  in  integer; 
count  :  out  integer); 
begin 

raise  UNDER.FLOW; 
end; 

end  self; 

function  Open-Port  (OB  ;  in  commonjobject.object) 
return  boolean  is  separate; 

procedure  Read_From-Port( 

OB  :  in  common-object. object; 

Buffer  :  in  out  string; 
num-chars-to_read  :  in  integer; 
count  :  out  integer)  is  separate; 

.  other  functions 
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end  port; 


The  subprograms  declared  in  the  inner  package  SELF  contain  the  Ada  image  of  the 
code  in  the  body  of  the  corresponding  methods.  For  example,  the  Read.From-Port  method 
declared  in  the  inner  package  SELF  contains  the  Ada  image  of  the  code  in  the  body  of  the 
PORT. 

Since  PORT  is  an  HEIR  only  of  COMMON.OBJECT  and  does  not  inherit  any  user- 
defined  method,  when  it  is  first  implemented  into  Ada,  there  is  only  one  version  of  each 
of  its  methods  known  to  the  system.  Until  the  subclass  of  PORT  is  added  to  the  library, 
therefore,  the  subprograms  declared  in  the  specification  of  the  corresponding  Ada  package 
are  essentially  redundant.  The  only  action  they  perform  is  to  call  the  corresponding  method 
contained  in  SELF.  The  body  of  the  exported  Open.Port  subprogram,  for  example,  has  a 
separate  body  of  the  form: 

separate  (Port) 

function  Open.Port  (OB  :  in  common.object.object)  return  boolean  is 
begin 

return  self.Open_Port(OB); 
end; 

At  this  stage,  this  subprogram  makes  no  useful  contribution  to  the  implementation 
of  the  method.  This  occurs  when  the  programmer  defines  new  versions  of  the  method 
in  subclasses.  The  subclass  of  PORT  that  does  this  is  the  class  Unmanaged.RS232-Port 
which  redefines  the  Open.Port.  When  Unmanaged.RS232.Port  is  implemented  into  Ada, 
the  separate  body  of  the  subprogram  PORT. Open.Port  is  replaced  by  the  following: 

with  Unmanaged.RS232-Port; 
separate  (Port) 

function  Open.Port  (OB  :  in  comraonjjbject. object)  return  boolean  is 
begin 

if  port.part_of(OB)  =  null  then 
return  self.Open_Port(OB); 
else 
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return  tJnmanaged-RS232_Port.Open_Port(OB); 
end; 

When  invoked,  this  function  analyzes  the  form  of  the  state  list  OB  to  see  whether 
the  state  list  represents  an  instance  oi  PORT  or  its  subclass  Unmanaged.RS232.Port.  If 
it  represents  the  latter,  it  invokes  the  Unmanaged.RS232.Port  version,  otherwise  it  invokes 
the  method  in  the  package  SELF.  Essentially,  therefore,  this  function  forms  a  kind  of  ‘shell’ 
around  the  true  method  implementations  in  order  to  select,  at  run-time,  the  appropriate  one 
for  execution. 

The  great  advantage  of  this  approach  is  that  all  the  modification  and  recompilation 
needed  to  cater  to  the  new  version  is  limited  to  the  ‘separate’  subprograms  of  the  methods 
concerned.  This  advantage  come  from  the  separation  of  the  meilu^d  selection  subprogram; 
that  is,  it  is  replaced  as  a  subunit  of  the  main  package.  Not  even  the  body  of  the  package,  let 
alone  the  Ada  code  for  clients  of  the  class,  needs  to  be  recompiled  when  methods  redefining 
subclasses  are  added  to  the  system. 

This  technique  is  fine  for  distinguishing  between  the  different  versions  of  a  method 
that  may  be  introduced  in  a  linear  inheritance  chain,  that  is,  when  each  class  has  only  one 
parent  and  one  child  class.  However,  if  a  parent  has  more  than  one  child  class,  before  using  a 
ParLO/ function  to  convert  its  type,  it  is  essential  to  determine  to  which  of  the  child  classes 
the  next  node  in  the  list  actually  corresponds.  Another  field  is  needed  in  the  nodes  of  the 
state  lists  to  indicate  in  which  of  the  branches  of  the  inheritance  tree  the  class  represented 
by  the  subsequent  node  lies.  The  Offspring.no  is  the  purpose  of  indicating  which  of  the  child 
classes  is  the  next  node  in  the  list.  Together,  the  Heir  and  Offspring.no  fields  of  state  nodes 
provide  all  the  information  needed  by  selection  shells  to  determine  which  version  of  a  method 
to  execute  in  response  to  a  call.  Suppose,  for  example,  that  the  Distributed.RS232.Port  was 
translated  into  the  package,  which  also  redefined  the  Open.Port.  Now  the  Offspring.no  field 
would  be  assigned  natural  number  1.  In  order  to  determine  the  appropriate  implementation 
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when  Open.Port  is  invoked  through  an  instance  variable  of  class  Distributed.RS232.Port,  the 
body  of  the  Open.Port  function  (selection  shell)  would  be  replaced  by  the  following  form: 

with  Unmanaged_RS232_Port; 
with  Distributed_RS232_Port; 
separate  (Port) 

function  Open.Port  (OB  :  in  common_object .object)  return  boolean  is 
begin 

if  port.part_of(OB)  =  null  then 
return  self.Open_Port(OB); 
else 

case  port.part_of(OB).ofFspring.no  is 
when  0  => 

return  Unmanaged-RS232_Port.Open-Port(OB); 
when  1  => 

return  Distributed.RS2.32.Port.Open_Port(OB); 
when  others  => 

raise  UNDER.FLOW; 
end; 


4.2.3  Clientship.  The  method  of  implementing  classes  in  this  thesis  makes  the 
translation  of  client  code  very  straightforward.  All  instance  variables,  of  whatever  class 
type,  are  translated  into  Ada  access  variables  of  type  CommonObject. Object  since  the  first 
node  of  all  state  lists  is  of  type  CommonObject.  Object.  The  translation  of  method  invocations 
employs  the  same  principle  used  in  the  simple  ADT  approach.  That  is,  the  Ada  access  vari¬ 
able  corresponding  to  the  called  object  is  supplied  as  the  first  parameter  of  the  subprogram 
implementing  the  method.  Thus  a  method  ‘Read_FroniJ*ort’  call  of  Urimanaged.RS232.Port 
would  be  translated  into  the  following  subprogram  invocations: 

Port.Read.From.Port 

(part_of(OB). instantiated JlS232,part_oi(OB). JOY Jioise.buffer,  JOYJ)ATA_SIZE,count); 


where  instantiated.RS232\s  a  instance  variable  .  ad  JOY.noise.buffer,  JOY.DATASIZE 
and  count  are  variables  for  method  invocation.  The  separated  Port.Read.From.Port  method 
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would  select  the  method  Unmanagtd.RS232.Port  class  at  run-time.  Now,  instantiated.RS232 
is  an  access  variable  of  type  Common.Object. Object  Similarly,  the  generation  of  objects  by 
invocation  of  CREATE  method  is  simply  translated  as  follows: 

instantiated_RS232  :  common_object.object; 

instantiated_RS232  := 

unmanaged-RS232_port.create_of(port_num,  port_speed,  port_mode,  port-type) 


4.3  Detailed  Design  and  Implementation  of  Reusable  a  Joystick  Component 

As  mentioned  in  the  previous  chapter.  Joystick  class  has  a  degree  of  concurrency.  The 
joystick  would  in  certain  modes  operate  independently  of  the  computer.  The  task  is  the 
unit  of  concurrency  in  Ada.  The  implementation  of  active  objects,  with  their  concurrent 
execution  threads,  must  clearly  be  based  on  the  use  of  tasks.  Because  a  task  is  defined 
in  terms  of  actions  rather  than  statements  or  instructions,  even  the  execution  of  a  single 
program,  such  as  a  procedure  which  prints  “Hello”  on  a  terminal,  can  be  viewed  as  a  single, 
implicit  task  whose  thread  of  execution  runs  in  parallel  with  the  rest  of  the  system.  In 
Ada,  tasks  allow  the  programmer  to  decompose  a  problem  into  several  independent  threads 
of  control.  These  techniques  enable  a  programmer  to  model  different  activities  in  the  real 

1  world  simultaneously.  For  example,  an  avionics  system  has  altitude,  radar,  joystick,  and  a 

1  .  . 

^graphics  display,  each  of  which  is  continudly  monitored  for  valid  reading.  Additionally,  the 
graphics  display  is  updated  periodically  to  reflect  position,  altitude,  velocity,  and  teri'ain. 
Each  of  these  subsystems  can  be  modeled  by  a  task.  These  tasks  are  independent  activities. 

1  The  one  problem  in  using  a  task  to  represent  the  thread  of  an  object  is  in  integrating 
it  with  the  state  list  representation  of  objects  used  so  far.  However,  this  can  be  overcome 
because  Ada  permits  tasks  generated  from  task  types  to  be  identified  by  access  variables 
that  can  be  included  in  the  appropriate  record  structure.  In  addition  to  the  fields  storing 


the  state  variables  of  the  objects,  the  state  node  of  active  objects  has  an  additional  field 
holding  a  reference  to  a  task.  The  active  class  Joystick  can  be  translated  into  a  package  with 
a  specification  of  the  form: 

package  Joystick  is 
type  variable; 

type  state  is  access  variable; 
type  thread-form; 

type  thread_ref  is  access  thread-form; 
type  variable  is  record 

RS-232port  :  commonjobject.object; 

JOY_mode  :  character; 

JOY-out_mode  :  character; 

JOY-buffer  :  Buffer-type; 

JOY-noise-buffer  :  buffer-type; 


joy-x,  joy-y  :  integer; 
joy  .1,  joy -2,  joy-3  :  integer; 
offspring-no  :  natural  :=  0; 

HEIR  :  commonjobject.object; 
thread  :  thread-ref; 

end  record; 

teisk  type  thread-form  is 

entry  get-coordinates(  OB  :  in  common-object.object; 

x-value  :  in  out  integer; 
y- value  :  in  out  integer; 
butl  :  in  out  integer; 
but2  :  in  out  integer; 
but3  :  in  out  integer; 
flag  :  in  out  boolean); 

end  thread-form; 

function  Joystick-view-of  is  new 

unchecked-Conversion(  source  =>  commonjobject.object, 

target  =»  state); 

procedure  get-coordinates  ( 

OB  :  in  commonjobject.object; 
x-value  :  in  out  integer; 
y-value  :  in  out  integer; 
butl  :  in  out  integer; 
but2  :  in  out  integer; 
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but3  :  in  out  integer; 
flag  :  in  out  boolean); 


The  procedure  get.coordinates  corresponds  to  the  task  entry  geLcoordinates  method 
used  to  activate  the  thread  of  active  classes.  Invocation  of  the  geLcoordinates  method  by 
a  client  of  an  active  object  is  thus  translated  into  the  invocation  of  the  geLcoordinates 
procedure  whose  body  is  of  the  form; 

package  body  joystick  is 


procedure  get.coordinates(  OB  :  in  commonjobject.object; 

x_value  :  in  out  integer; 
y.value  :  in  out  integer; 
butl  :  in  out  integer; 
but2  :  in  out  integer; 
but3  :  in  out  integer; 
flag  :  in  out  boolean)  is 

begin 

joystick.part_of(OB). thread  :=  new  threadJorm; 
joystick.part_of(OB).thread.get_coordinates 
(OB, X-value, y.value, butl, but2,but3, flag); 

end  get-coordinates; 


end  joystick; 

The  first  action  performed  by  this  procedure  is  to  instantiate  the  task  type  thread.form 
and  assign  its  access  value  to  the  thread  field  of  the  state  node  associated  with  Joystick.  The 
procedure  then  calls  the  geLcoordinates  method  of  the  task  to  give  it  the  reference  to  the  state 
list  so  that  the  thread  may  manipulate  the  variable  of  the  objects.  The  calling  of  this  entry 
also  serves  to  unblock  the  tasks  so  that  it  may  begin  execution  of  the  code  corresponding  to 
the  body  of  the  thread.  The  thread.form  task  type  therefore  has  the  following  body: 

package  body  joystick  is 
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task  body  thread_form  is 
begin 
loop 

accept  get.coordinates(  OB  :  in  conimon_object.object; 

x_va.lue  :  in  out  integer; 
y.value  :  in  out  integer; 
butl  :  in  out  integer; 
but2  :  in  out  integer; 
but3  :  in  out  integer; 
flag  ;  in  out  boolean)  is 

joystick. read_joystick(OB,x_value, y.value, but  I,but2,but3, flag); 
end  get.coordinates; 
end  loop; 
end  thread.form; 


end  joystick; 

Once  the  get.coordinates  procedure  has  generated  an  instance  of  task  type  thread.form 
and  provided  it  with  a  reference  to  the  object’s  state  list  by  calling  its  get.coordinates  entry, 
the  task  will  execute  concurrently  with  other  threads  and  method  invocations,  as  required.  • 

Moreover,  as  it  is  included  in  the  state  node  of  the  corresponding  objects,  it  is  intimately 
associated  with  the  corresponding  object  state  for  the  duration  of  the  program.  For  example, 
consider  simplified  versions  of  the  flight  simulator  task  units  “request.task.type”  which  may 
trigger  a  long  input  operation  task  “get.coordinates”.  Each  “request.task.type”  task  calls 
task  “get.coordinates”  to  determine  the  current  position  of  a  moving  object,  based  on  the 
X,Y-coordinates  of  the  corresponding  joystick.  These  tcisks  communicate  by  sending  each 
other  not  only  synchronization  information,  but  data  as  well.  The  message  passing  concept 
in  Ada  is  called  the  rendezvous.  After  the  rendezvous  is  complete,  the  two  tasks  continue 
independently. 
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4-4  Detailed  Design  and  Implementation  of  the  Ada  Wrapper 

The  Adawrapper  class  was  intended  zis  a  wrapper  class  in  which  C++  class  members 
of  data  and  function  were  interfaced  with  Ada  code.  Basically,  two  approaches  were  taken; 
one  through  the  C-linkage  (e.g.,  extern  ”0”  {  },  which  says  that  everything  within  the 
scope  of  the  brace-surrounded  block  is  compiled  by  a  C  compiler),  and  the  other  through 
the  type-safe  linkage  and  name  encoding  technicjues.  This  section  describes  the  problems 
involved  in  generating  names  for  overloaded  functions  in  C++  and  in  linking  to  Ada  and 
C++  programs.  It  also  discusses  how  problems  referred  to  in  this  thesis  were  .solved. 

The  type-safe  linkage  and  name  encoding  technique  (C++-linkage)  discussed  in  this 
thesis  was  bcised  on  the  2.0  release  of  C++.  C++,  like  a  Ada,  allows  overloading  of  function 
names;  two  functions  may  have  the  same  name  provided  their  argument  types  are  different, 
while  C  does  not  provide  function  name  overloading.  C  has  a  simple  naming  convention  for 
external  symbols,  which  includes  global  variable  and  function  names.  The  C  compiler  just 
prepends  an  r.nderscore  character  to  external  symbols.  This  simple  scheme  clearly  isn’t 
sufficient  to  cope  with  overload  functions.  However,  in  C++,  every  function  name  is  encoded 
by  appending  its  signature. 

The  C++  function  name  encoding  scheme  was  originally  designed  primarily  to  allow 
the  function  and  cla.ss  names  to  be  reliably  ex'racterl  from  encoded  class  member  names. 
The  basic  approach  is  to  append  a  function’s  signature  to  the  function  name.  According  to 
the  AT&:T  C++  Language  System  Selected  Reading7s{A),  the  function  name  encoding  scheme 
under  C++  version  2.0  is  defined  as  shown  in  tabic  4.4. 

A  global  function  name  is  encoded  by  appending  _F  followed  by  the  signature  .so  that, 
for  example,  Read-Packet (int,  char,  float)  becomes  Read.Packe t..Ficf.  Within  Ada,  this 
function  should  be  called  through  the  encoded  name  ‘■Read-Packet_Ficf’.  Thus  when  the 
port  was  being  set  up  for  “raw”  input  allowing  the  port  to  receive  in])uts  present  in  (he 
read  queue  (regardless  of  whether  the  tty  device  is  done  scuiding  a  full  pa<-ket  or  not),  the 
tty.set-tty_state  Ada  function  was  used  .  This  function  was  j)rovidcd  by  the  VADS  ‘veidixlib* 
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library.  However,  the  function  didn’t  set  up  the  port  correctly.  Additional  parameters  were 

! 

set  up  and  blocked  the  terminal.  For  the  safety  of  the  terminal  set,  a  C++  function  was 
written  to  set  the  port  up  for  “raw”  rather  than  Ada  function.  Then  the  C++  function 
was  called  within  Ada.  To  bind  with  C++,  the  parallel  data  types  between  Ada  and  C++ 
were  created.  Creation  of  parallel  data  types  was  the  same  as  C,  \Yhich  meant  that  C  and 

C++  have  basically  the  same  data  representations.  Then  the  C++  function  name  encoding 

i 

scheme  was  used  to  access  that  C++  function  within  Ada.  ' 

with  system; 

Package  Unmanaged-RS232_Port  is 

procedure  c_port_port(  port.FD.num  :  in  system. addres.s, 

ttyport  :  in  system. address; 
port.speed  ;  iu  system. address; 

P.mode  :  in  system. address); 

pragma  IN  i  ERFACE  (C,  c.port.open); 

pragma  INTERFACEJ'JAME  (c.port.open,  &  “c.port.open__FPiPcN2”); 


I 

i 


,  ‘  -»[ 


Package  Body  Unmanaged_RS232_Port  is  ,  ‘  , 

port.FD.num  :  integer;  '  - 

ttyport  :  string(l..ll);  V 

P.mode:  integer; 
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ttyport(1..8)  :=  ’’/dev/tty”; 
ttyport(ll)  :=  ascii. mil; 

P_mode  :=  port.port_input.mode’pos(part_of(OB).portjnode); 

c_port-open(port_FD_num’address,ttyport’address, 

part_of(  OB )  .port  .speed ’address, P.mode’address) ; 

end  Unmanaged-RS232-Port 

Corresponding  C++  program 

c-port_port(int  *FD,  char  path  [],  int  *port_speed,  int  *P_mode) 

{ 

} 

Another  way  of  accessing  C++  global  functions  within  Ada  was  to  use  the  C-linkage 
instead  of  the  C++-linkage.  The  extern  “C”  statement  means  that  everything  within  the 
scope  of  the  brace-surrounded  block  is  compiled  by  a  C  compiler.  With  this  approach,  the 
function  was  accesses  through  pragma  INTERFACE  within  Ada.  All  procedures  to  access 
C++  functions  within  Ada  are  basically  the  same  as  that  of  the  C++-linkage  except  for  the 
encoded  function  name. 

pragma  INTERFACE  (C,  c.port.open); 

pragma  INTERFACEJ^AME  (c.port.open,  C.SUBP JREFIX  &  “c.port.open”); 
Corresponding  C++  program 

extern  ”C”  c.port. port  (int  *FD,  char  path  [],  int  *port.speed,  int  *P.mode) 

{ 

} 

Stroustrup  suggested  the  linkage  from  C++  to  another  language  as  follows:  “I  conjec¬ 
ture  that  in  most  cases  linkage  from  C++  to  another  language  is  best  done  simply  by  using  a 
common  and  fairly  simple  convention  such  as  ‘C-linkage’  plus  some  standard  library  routines 
and/or  rules  for  argument  passing,  format  conversion,  etc.,  to  avoid  building  knowledge  of 
non-standard  calling  conventions  into  C++  compilers”  (4:6-9).  As  he  suggested,  the  use 
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of  ‘C-linkage’  instead  of  C++-linkage  made  interfacing  with  Ada  simpler  for  unique  name 
global  C++  functions. 

However,  there  are  several  problems  with  ‘C-linkage’  for  overloading  functions  and 
class  members.  The  first  is  a  safety  problem  with  function  overloading.  ‘C-linkage’  basically 
can  not  overload  functions,  since  two  functions  with  the  same  function  name  and  different 
signatures  can  cause  serious  side  effects.  The  second,  and  more  serious,  problem  with  ‘C- 
linkage’  was  related  to  a  class  and  its  members.  A  linkage  specification  for  classes  applied 
to  only  non-member  functions  and  objects  declared  within  it.  There  was  no  way  of  using 
‘C-linkage’  for  C++  classes  and  their  members,  which  means  that  every  linkage  specification 
for  classes  and  their  members  should  use  C++  naming  encoding  techniques. 

'  According  to  the  C++  name  encoding  technique,  names  of  classes  was  encoded  as  the 
length  of  the  name  followed  by  the  name  itself  to  avoid  terminators.  For  example,  the  member 
function  of  joystick  class,  Set_Y_Normalize(int&:),  becomes  Set.Y-Normalize_8JoystickFRi. 
The  procedure  of  binding  with  this  class  member  function  was  basically  the  same  as  that  of 
C++  global  functions.  The  details  within  Ada  are  as  follows: 

procedure  Set_Y_Normalize  (Nl  :  in  integer); 
pragma  INTERFACE  (C,Set_Y .Normalize); 

pragma  INTERFACE J'fAME(Set_Y_Normalize,’’Set_Y_Normalize_8JoystickFRi’’); 

The  main  problem  with  this  approach  is  that  the  instances  of  C++  classes  are  not 
exported  from  C++  to  Ada.  That  is,  Ada  could  not  instantiate  the  C++  class  from  within 
Ada  because  class  definition  in  C++  does  not  cause  any  memory  to  be  allocated.  Memory 
is  allocated  for  a  class  with  the  definition  of  each  class  object. 

At  first,  an  intermediate  C  routine  which  transfers  C++  class  structure  to  Ada  was 
tried.  The  problem  was  the  same  as  with  Ada’s  case.  Neither  Ada  nor  C  can  export  C++ 
class  data  structures  to  create  instances  of  C++  classes.  One  possible  way  of  exploiting  a 
class  library  from  Ada  was  to  use  pointers  to  class  members  and  itself,  which  was  the  first 
approach  taken.  It  seemed  possible  because  we  were  able  to  create  prirallel  data  structures 


4-18 


corresponding  to  pointers  of  class  data  members  and  declare  subprograrhs  corresponding  to 
class  function  members  according  to  the  C++  naming  encoding  rules.  In  C++,  a  pointer 
to  an  object  of  a  class  points  to  the  first  byte  of  that  region  of  memory.  The  C++  compiler 
turns  a  call  of  a  member  function  into  an  “ordinary”  function  call  with  an  extra  argument; 
that  extra  argument  is  a  pointer  to  the  object  for  which  the  member  function  is  called  (4:5-2). 
For  example,  a  simple  class  Joystick: 

clciss  Joystick  { 

int  x,y,butl,but2,but3; 

void  read_joystick(int  x,int  y,int  butl,  int  but2,  int  but3); 

}; 

A  call  of  the  member  function  Joystick::read_joystick: 

Joystick  *ptrjoystick;  -pointer  to  Joystick  class 
ptrjoystick=»read.joystick(x,y,butl,but2,but3); 

is  transformed  by  the  compiler  into  an  “ordinary  function  call”: 

read.joystick_F8Joystick(ptrjoystick,x,y,butl,but2,but3); 

From  the  above  ordinary  function  call,  Ada  may  be  able  to  access  individual  C++ 
class  members  through  another  intermediate  C++  global  function  which  just  creates  an 
instance  of  a  class.  However,  we  were  not  able  to  exploit  class  members  within  Ada  from 
the  C++  class  library.  Later,  we  found  out  there  was  no  pointer  to  a  class  member  under 
C++  compiler  version  2.0 

Another  way  of  exploiting  the  C++  classes  library  was  to  build  a  C++  main  function 
which  instantiates  the  classes  and  invokes  the  member  functions.  Then  Ada  can  access  the 
C++  main  function  directly  through  Ada  pragma  INTERFACE.  Within  C++  main,  object 
attributes  (parameters)  are  passed  to  the  Ada  routine  by  calling  Ada  subprograms.  For 
example,  the  Ada  main  program  calls  the  C++  main  program  just  like  calling  the  C++ 
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global  functions.  And  the  C++  main  program  passes  object  data  members  as  parameters 
by  invoking  the  Ada  subprogram  within  the  Ada  main  program. 


procedure  joyadatest  is 

procedure  joyt; 

pragma  interface  (C,  joytl; 

pragma  interface jiame  (joyt,’’joy__Fv”); 

procedure  getdata(  x.val  :  in  integer; 

y.val  :  in  integer; 
but-l  :  in  integer; 
but_2  :  in  integer; 
but-3  :  in  integer; 
flag  :  in  integer); 

pragma  EXTERNAL  (C,  getdata); 

pragma  EXTERNAL^AME  (getdata,  C.SUBP.PREFIX  k  ”givedata_FiN5r); 
procedure  getdata(x_val  :  in  integer; 

y_val  :  in  integer; 
but.l  :  in  integer 
but.2  :  in  integer; 
but_3  :  in  integer; 
flag  ;  in  integer)  is 

begin 


-perform  something 


end  getdata; 
begin 

joyt; 


end; 


C++  program 
extern  "C” 

{ 

int  x-val  =  0; 
other  declarations 

} 

extern  givedata  (int,  int.  int,  int,  int,  int); 

Joystick  *ptr; 
joyO 
{ 

Joystick  jstick(Port::portJ'our); 
ptr  =  (fcjstick; 

ptr=»Set_Y_Normalize(TRUE); 

ptr=>’Set.Y_Resolution(10); 
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while  ((!(but_l))) 

flag  =  jstick.ReadJoystick(&x_vaI,  &:y_val,  &but_l,  &but_2,  &but_3); 
givedata(x_val,y_val,but-l,but_2,but_3,flag); 

} 

} 


For  the  Adawrapper  class,  we  first  tried  to  replace  DISTPORT  class  with  an  Ada 
routine,  because  its  only  function  is  to  create  a  PORT  READER  class  object  and  call  the  read 
method.  However,  we  couldn’t  find  the  way  of  directly  exploiting  a  class  library  within  Ada. 


The  Adawrapper  vf as  needed  to  access  C++  class  DISTPORT.  Actually  the  DISTPORT  was 


the  main  program  that  instantiates  a  class  ‘Port  Reader  \  then  runs  on  a  remote  machine.  The 
DISTPORT  was  invoked  by  passing  the  parameters,  which  are  the  command  line  arguments 
in  argc  and  argv. 

i 

with  system;  use  system;  | 

with  language;  use  language;  j 

with  commandJine;  use  commandJine; 
procedure  distportada  is  | 

procedure  distport(  argc  :  in  system. address; 

argv  :  in  ^ystem. address); 
pragma  interface  (C,  distport); 

pragma  interface-name  (distport,C-SUBP_PREFIX  h  "main”); 
begin 

distport(argc’address,argv’address); 

end; 


Appendix  B  includes  some  programs  to  help  in  the  understanding  of  the  example  pro¬ 
gram  code  explained  in  this  chapter.  All  programs  included  in  Appendix  B  were  implemented 
for  developing  the  reusable  joystick  component  for  a  flight  simulator  application  domain. 
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V.  Summary  and  Conclusions 

This  chapter  summarizes  the  research  discussed  in  this  thesis  and  also  presents  con¬ 
clusions. 

5.1  Summary 

The  objective  of  this  thesis  was  to  develop  a  set  of  reusable  software  components  for 
investigating  and  for  demonstrating  Ada’s  applicability  as  an  implementation  language  for 
a  reusable  graphical  software  component. 

A  set  of  components,  Reusable  Joystick  and  RS232-Port,  were  developed  for  a  flight 
simulator.  The  00  approach  was  applied  to  the  implementation  of  these  components  using 
the  Ada  programming  language  associated  with  C-h-l-  components. 

The  development  of  this  thesis  started  with  an  analysis  of  the  flight  simulator  domain. 
The  main  purpose  of  the  analysis  phase  was  to  identify  potential  reusable  software  compo¬ 
nents.  This  came  from  a  domain  analysis  that  led  to  the  identification  of  common  objects, 
operations,  and  structures.  A  class  was  a  set  of  objects  that  share  a  common  structure  and 
common  behavior.  Each  object  class  was  a  candidate  for  a  reusable  component  for  the  do¬ 
main.  This  thesis  identified  low  level  inputs  (Joystick  and  RS232  port  cl^lsses)  as  a  reusable 
components  implementation. 

The  next  step  was  to  analyze  the  joystick  and  the  RS232  port  classes  and  their  re¬ 
lationship  among  their  class  members  in  more  detail.  As  a  part  of  this,  Ada  binding  to 
C-|— h/C  was  analyzed.  For  a  complete  Ada  binding  to  a  C-f-|-/C  library  and  existing  codes, 
the  following  steps  are  necessary. 

•  Create  parallel  data  types. 

•  Interface  to  external  symbols  (routine  and  data). 

•  Link  to  external  libraries. 
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Whenever  access  to  routines  or  variables  declared  in  the  C++/C  language  is  required,  any 
Ada  variables  used  in  conjunction  with  the  subroutines  or  variables  are  compatible  with  the 
C++/C  data  representation.  Once  these  parallel  types  have  been  established,  the  next  step 
is  to  gain  access  to  external  routines  and  data  provided  in  the  interface  target  language.  This 
is  accomplished  in  a  two  stage  procedure:  first,  equivalent  Ada  subprogram  specifications 
are  written,  and  second,  the  linkage  to  the  external  routine  and  data  is  declared.  The 
first  step  is  a  simple  mapping  of  external  routine  and  data  names  and  parameters  into  an 
Ada  subprogram  specification.  The  second  step  is  accomplished  through  use  of  the  pragma 
INTERFACE  and  pragma  INTERFACE.NAME.  Linking  the  symbols  built  in  Ada  with  the 
external  C+4-/C  symbols  is  done  by  the  Ada  linker. 

Then  design  decisions  were  made  and  details  were  added  to  the  model  to  describe  and 
optimize  the  implementation.  The  main  goal  in  designing  and  implementing  each  component 
was  ease  of  use  and  reusability  (extensibility  and  maintainability  were  derived  from  designing 
for  reusability).  The  design  of  such  reusable  software  components  resulted  in  a  design  which 
incorporates  an  interface  and  an  implew.entation,  resulting  in  the  design  of  an  abstraction. 
Components  that  incorporate  such  characteristics  are  usually  referred  to  as  objects  and  are 
said  to  be  object-oriented.  OOD  of  reusable  Joystick  and  RS232  Port  components  was  used. 
This  model  focused  on  reusability  in  C-f-)-.  Redesign  Wcis  required  for  adapting  to  the  Ada 
culture.  The  “Ada_wrapper”  for  wrapping  C-I-+  routines  was  added  to  surround  the  C-)--|- 
class  members  and  allow  them  to  be  gradually  replaced  later. 

Several  methods  for  building  a  well-engineered  reusable  component  were  considered. 
Each  alternative  achieves  this  goal  of  building  reusable  components  by  demonstrating  some 
effect  of  Object-Oriented  (00)  mechanisms  through  Ada  language  features. 

The  most  direct  representation  of  an  object  is  a  state  encapsulating  package  exporting 
a  set  of  operations  which  can  be  used  to  access  and  update  the  object  state.  With  this 
Abstract  State  Machine  (ASM)  approach,  the  user  is  provided  with  a  high-level  interface  to 
the  components.  All  access  is  through  the  operations  provided  in  the  interface.  A  generic 
state-encapsulating  package  with  this  interface  defines  an  object  template  from  which  mul- 
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tiple  structurally  identical  instances  can  be  generated.  However,  generic  packages  are  static 
entities  that  can  only  be  instantiated  at  compile  time  and  thus  do  not  support  the  con¬ 
cept  of  dynamically  instantiatable  objects  identified  by  references,  let  alone  support  for  the 
accompanying  mechanisms  of  inheritance,  polymorphism  and  dynamic  binding. 

The  second  method  is  to  represent  objects  as  tasks.  This  method  can  support  dynam¬ 
ically  instantiatable  classes  and  the  notion  of  concurrency.  It  can  also  be  used  to  realize  a 
form  of  dynamic  binding.  However,  the  problem  with  this  method  is  that  classes  emulated 
by  task  types  in  Ada  cannot  provide  support  for  inheritance.  Another  problem  is  that  they 
cannot  be  library  units. 

In  addition  to  the  above  two  approaches,  the  notion  of  Abstract  Data  Type  (ADT) 
can  be  used  for  representing  objects  and  classes.  In  this  method,  an  object  is  defined  by 
a  package  exporting  an  ADT.  This  approach  differs  from  the  ASM  approach  in  that  the 
interface  consists  of  both  the  predefined  set  of  operations  and  the  data  structure  itself, 
but  the  state  of  the  data  is  not  captured.  The  package  exporting  the  type  and  associated 
methods  does  not  itself  represent  an  object  but  rather  variables  of  the  exported  data  type, 
and  the  package  defining  the  ADT  corresponds  more  to  a  class,  therefore,  than  to  an  object. 
The  reference  semantics  and  the  dynamically  instantiated  objects  are  provided  by  making 
the  exported  type  an  access  type  rather  than  a  static  type.  The  main  advantage  of  th’s 
method  is  that  it  provides  limited  support  for  two  important  mechanisms  associated  with 
classes/objects,  inheritance  and  polymorphism.  However,  it  introduces  limitations  such  as 
type  incompatibility  by  deriving  from  the  parent  types,  narrowing  their  applicability  by 
subtyping,  recompilation  of  the  original  abstraction  by  breaking  the  original  abstraction, 
and  complicated  generic  parameters. 

Another  method  for  representing  classes  and  objects  is  to  use  Ada  generic  units  to 
provide  components  which  are  tailorable  to  user-defined  types.  It  provides  flexibility  while 
simplifying  use.  Types  and  operations  on  the  types  are  defined,  and  the  types  can  then 
be  used  to  instantiate  the  generics,  and  the  operations  will  get  pulled  along.  The  major 
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advantage  of  this  approach  is  that  it  incorporates  strong  typing  and  is  flexible.  However,  the 
user  would  need  to  supply  a  large  number  of  generic  parameters. 

Ada  9X  Wcis  considered  as  the  best  solution  since  it  provides  support  for  the  paradigm 
of  object-oriented  programming  (OOP)  through  powerful  mechanisms  for  variant  and  class¬ 
wide  programming  and  child  library  units.  All  limitations  with  the  Ada  83  ADT  approach 
can  be  addressed  with  Ada  9X.  With  Ada  9X,  the  programmer  can  use  tagged  type  extension 
and  subprogram  dispatch  to  simplify  the  system.  Tagged  types  offer  Ada  programmers  a 
mechanism  for  single  inheritance.  For  a  type  T,  the  class-wide  type  T’Class  was  introduced. 
The  set  of  values  of  T’Class  is  the  union  of  the  sets  of  values  of  T  and  all  of  its  derivatives. 
The  type  tag,  associated  with  each  value  of  a  tagged  class-wide  type,  is  the  basis  for  adding 
run-time  polymorphism  in  Ada  9X.  However,  an  Ada  9X  compiler  was  not  available. 

The  last  alternative  considered  was  an  ADT  with  a  common  class  approach.  The 
main  difference  between  this  approach  and  the  simple  ADT  approach  is  that  the  state  of 
the  object  is  not  represented  by  a  single  record  but  by  a  linked  lii;t  of  records.  Each  node 
in  the  list  stores  the  state  variables  added  by  its  ancestors.  In  this  approach,  all  objects 
in  the  component  are  represented  by  state  lists  whose  first  node  is  a  record  of  type  Coin- 
mon.Object.State,  referenced  by  an  access  variable  of  type  Common.Object,  Object.  These 
state  lists  corresponding  to  descendants  of  Common-Object.  Object  are  composed  of  a  Com- 
mon-Object.State  record  followed  by  records  holding  the  sta^e  variable  introduced  by  each 
of  the  clcisses  in  the  inheritance  chain.  Since  the  first  node  of  every  ^tate  list  is  of  the  type 
Common.Object.State,  all  objects  in  the  component  are  referenced  bv  access  values  of  the 
same  Ada  type  “Common-Object. Object”.  This  was  the  basic  strategy  for  overcoming  the 
incompatibility  of  the  polymorphism,  inheritance  mechanism  and  dynimic  binding  without 
introducing  type  incompatibility  and  recompilation  while  preserving  Ada’s  strong  typing 
mechanism.  The  only  problem  with  this  approach  is  that  it  introduces  unnecessary  Com¬ 
mon-Object  classes  and  attributes  for  making  each  class  link.  For  example,  all  classes  are 
inherited  from  the  Common-Object  class,  and  have  two  additional  attributes  -  Offspring-no 
and  Heir  which  are  not  essential  to  them. 


.\ 
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This  ADT  with  common  class  approach  was  selected  for  implementation.  The  inheri¬ 
tance  and  polymorphism  mechanisms  were  accomplished  through  the  linked  list  which  has  a 
common  object  access  type.  All  objects  in  the  system  are  of  type  Common.Object. State  ref¬ 
erenced  by  an  access  variable  of  type  Common-Object. Object.  Not  only  does  this  mechanism 
solve  the  problem  of  polymorphism,  but  it  also  means  that  there  are  no  typing  obstacles  to 
the  incremental  introduction  of  new  subclasses,  since  instances  of  these  are  also  represented 
by  state  lists  referenced  by  accessed  variables  of  type  Common.Object. Object. 

For  example,  if  the  HEIR  field  of  the  first  node  is  ‘null*,  the  iist  represents  an  instance 
of  class  Common.Object]  if  not,  then  it  corresponds  to  a  descendant  of  Common.Object  and 
therefore  can  be  supplied  as  a  parameter  to  a  method  of  a  descendant  class. 

In  a  linear  inheritance  hierarchy,  the  process  of  adding  nodes  to  the  list  is  repeated  for 
each  new  addition  to  tl  c  hierarchy.  As  illustrated  in  the  previous  chapter,  the  state  of  an 
Unmanaged.RS232.Port  object  is  stored  as  a  linked  list  of  three  nodes.  The  Ada  package 
into  which  Unmanaged.RS232.Port  is  translated,  however,  is  completely  independent  of  the 
record  types  used  to  generate  the  first  two  nodes  in  the  list.  The  Unmanaged.RS232.Port 
structure  is  not  affected  in  any  way  by  that  of  the  package  Port  corresponding  to  its  parent 
class.  The  only  place  in  which  reference  is  made  to  this  package  is  in  the  implementation  of 
the  Create  and  Part.Oj.  The  key  benefit  of  this  mechanism  is  in  the  structure  of  these  two 
functions. 

Ada’s  features  for  defining  the  bodies  of  methods  in  physically  separate  subunits  pro¬ 
vides  an  elegant  mechanism  of  dynamic  binding.  It  permits  the  amount  of  code  that  has  to 
be  updated  to  cater  to  the  introduction  of  new  method  versions  to  be  limited  to  a  single 
procedure  body.  None  of  the  subprograms  declared  in  the  package  specification  actually 
implements  the  corresponding  method  directly,  however.  This  job  is,  in  fact,  performed  by 
an  additional  set  of  methods  declared  in  a  package  5£'LF  contained  in  the  body  of  the  main 
package.  The  bodies  of  the  visible  subprograms  declared  in  the  specification  of  the  main 
package  are  contained  in  ‘separate  ’  units  and  use  the  subprograms  defined  in  inner  package 
SELF  to  implement  the  original  method.  The  great  advantage  of  this  approach  is  that  all  the 
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modification  and  recompilation  needed  to  cater  to  the  new  version  is  limited  to  the  ‘separate’ 
subprograms  of  the  methods  concerned. 

The  Adawrapper  class  was  intended  as  a  wrapper  class,  in  which  C++  class  members 
of  data  and  function  were  interfaced  with  Ada  code.  Basically,  two  approaches  were  taken; 
one  through  the  C-linkage  (e.g.,  extern  ”0”  {  }  which  says  that  everything  within  the  scope 
of  the  brace-surrounded  block  is  compiled  by  a  C  compiler),  and  the  other  through  the 
type-safe  linkage  and  name  encoding  techniques  -  C++-Linkage. 

One  way  of  accessing  C+-1-  global  functions  within  Ada  was  to  use  the  C-linkage  instead 
of  the  C++-linkage.  The  extern  “C”  statement  says  that  everything  within  the  scope  of  the 
brace-surrounded  block  is  compiled  by  a  C  compiler.  With  this  approach,  the  function  was 
accessed  through  pragma  INTERFACE viMhAn.  Ada.  All  procedures  to  access  C++  functions 
within  Ada  are  basically  the  same  as  that  of  the  C++-linkage  except  for  encoded  functions. 
The  use  of  ‘C-linkage’  made  Ada  interfacing  with  C++  simple  for  uniquely  named  global 
C++  functions. 

However,  there  are  several  problems  with  ‘C-linkage’  for  overloading  functions  and 
class  members.  The  first  is  a  safety  problem  with  function  overloading.  ‘C-linkage’  basically 
cannot  overload  functions,  since  two  functions  with  the  same  function  name  and  different 
signatures  can  cause  serious  side  effects.  The  second,  and  more  serious,  problem  with  ‘C- 
linkage’  was  related  to  a  class  and  its  members.  A  linkage  specification  for  classes  applied 
to  only  non-member  functions  and  objects  declared  within  it.  There  was  no  way  of  using 
‘C-linkage’  for  C+-|-  classes  and  their  members,  which  means  that  every  linkage  specification 
for  classes  and  their  members  should  use  C++  nei-ing  encoding  techniques. 

Another  way  of  accessing  C++  functions  was  to  use  ‘‘C++  linkage”.  A  global  func¬ 
tion  name  is  encoded  by  appending  _F  followed  by  the  signature  so  that,  for  example, 
Read_Packet(int,  char,  float)  becomes  Read.Packet..Ficf  since,  within  Ada,  this  function 
should  be  called  the  encoded  name  ‘Read_Packet_Ficf’.  Names  of  classes  are  encoded 
as  the  length  of  the  name  followed  by  the  name  itself  to  avoid  terminators.  For  exam- 
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pie,  the  member  function  of  the  joystick  class,  Joystick::Set.Y  Normalize(int&)  becomes 
Set_Y_Normalize_8JoystickFRi.  The  procedure  of  binding  with  this  class  member  function 
was  beisically  the  same  as  that  of  C++  global  functions. 

The  main  problem  with  using  C++  linkage  was  that  the  instances  of  C++  classes  are 
not  exported  from  C++  to  Ada.  That  is,  Ada  could  not  instantiate  the  C++  class  from 
within  Ada.  Neither  Ada  nor  C  export  C++  class  data  structures  to  create  instances  of 
C++  classes.  One  way  of  exploiting  C++  class  libraries  was  to  build  a  C++  main  function 
which  instantiated  the  classes;  then  Ada  accessed  the  C++  main  function  directly  through 
Ada  pragma  INTERFACE. 

5.2  Conclusions 

One  of  the  objectives  of  this  thesis  was  to  build  a  set  of  reusable  flight  simulator 
components  in  Ada  using  an  00  approach.  I  wanted  to  end  up  with  joystick  and  RS232  port 
components  that  were  reusable,  maintainable  and  extensible.  Object-oriented  techniques 
with  Ada  promised  to  provide  a  way  to  achieve  these  goals.  I  believe  that  these  goals  have 
been  accomplished. 

The  use  of  Ada,  however,  couldn’t  itself  guarantee  that  a  component  would  be  readily 
reusable.  There  were  a  number  of  important  design  guidelires  that  can  greatly  enhance  the 
reusability  of  components.  These  guidelines  relate  to  the  design  and  structure  of  reusable 
components  which  were  provided  by  the  00  approach. 

However,  there  were  limitations  with  Ada  83  such  as  type  incompatibility  and  recom¬ 
pilation,  or  introduction  of  attributes  which  are  not  essential  to  an  object.  Ada  9X  addressed 
these  limitations. 

Another  objective  of  this  thesis  was  to  build  a  set  of  reusable  Ada  software  components 
associated  with  C++  routines.  I  wanted  to  end  up  with  the  advanced  Ada  language  features 
that  could  access  the  C++  library.  However,  it  was  not  possible  to  export  members  of  classes 
and  objects  from  class  libraries  within  Ada.  It  was  possible  to  access  C++  global  functions 
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and  user-dofined  data  types,  but  not  tiser-defined  classes.  However,  one  feasible  way  was  to 
use  “ordinary’  function  calls  with  an  extra  argument;  that  extra  argimient  is  a  pointer  to 
the  object  for  which  the  class  member  function  is  called. 

It  is  currently  practical  to  use  Ada  for  graphics  applications  if  graphics  libraries  arc 
written  in  C  rather  than  C++.  However,  it  is  not  practical  to  use  Ada  for  C++  class  graphics 
libraries. 

5.3  R(  commendation.^ 

There  are  many  different  areas  of  the  design  and  implementation  techiiiques  to  build 
reusable  graphics  software  components  that  could  be  extended  and  improved.  This  thesis 
work  does  not  provide  the  best  solution  to  the  question  “hoic  to  develop  reusable  software 
components  in  Ada  which  are  associated  with  a  C++  class  library  that  is,  it  is  not  suitable 
for  a  “cookbook”  approach.  This  thesis  has  addressed  several  ways  of  building  a  reusable 
graphics  software  component  in  Ada  associated  with  C++  routines  using  an  00  approach. 

As  Ada  9X  translators  becomes  available,  this  work  can  be  implemented  much  more 
cleanly  and  directly  in  Ada  9X.  To  best  addre.ss  reusability  with  respect  to  interfacing  with 
C++,  Ada  9X  implementations  should  add  interface  facilities  which  enable  the  Ada  9X 
translator  to  choose  a  storage  layout  for  objects  of  the  named  types  and  user-defineu  classes 
in  C++  to  match  the  representation  that  the  C++  compiler  uses.  In  addition,  it  must 
be  possible  for  an  Ada  object  of  any  of  the  types,  including  storage  layout  for  objects  of 
user-defined  classes  in  C++,  to  be  passed  as  a  parameter  to  a  C++  function  with  the 
corresponding  formal  parameter. 
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Appendix  A.  Joystick  and  RS232Port  Design 


Figure  A.2.  Joystick  and  RS232  Port  Class  Hierarchy 
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Figure  A. 7.  A  .lawrapper 


Appendix  B.  Example  Source  Program  List 

. . . . * . 

WFll*  naB«  :  C.Port.Open.cc  • 

WPrrposa  :  It  reset  the  earlablea  in  the  teniio  structnra  to  represent* 

\\  the  saj  in  ehich  yon  eish  the  port  to  behave .  '  open  the* 

\\  port .  • 

. . 

eitom  "C"  { 

tinclnda  <ays/taniio  .h> 

int  loctl  (int,  int,  char*); 

> 

•inclnde  <3tdio.h> 
tiaclnde  <fcntl.h> 
tinclude  <atrlng.h> 

extern  "C"  void  c_port_open(lnt  *FD,  char  path[],lnt  *port.spaad,  int  *P_aioda> 

{ 

int  port.FD; 
struct  tenia  tty; 

if  ((port.FD  >  open(path,  O.RDVR  I  O.IOELIY))  »  -1) 

{ 

fprintfCstderr, "Cannot  open  port.W); 

fprintf (atderr."Rost  likely  cansa  is  that  penissions  file.\n“); 

} 

else 

ioctl (port.FD,  TCGETl,  (char  •)  ktty); 

/*  loe  reset  the  variables  in  the  tanio  structure  to  represent  the  say 
in  shich  yon  sish  the  port  to  behave  */ 

/• 

e  Set  the  pert  up  for; 
e  Bang  up  on  last  close 

e  eight  bits 

*  local  line 

e  enable  receiver 

e  enable  signals 

e  user  specified  band  rats 
*/ 

if  (*P_>oda  »  0)  /*  input  Boda  is  raw  */ 

{ 

fprintf (atdarr,"Ras  BOdeVn"); 

/*  These  flags  sat  up  the  port  for  "ras"  input .  This  alloss  us  to 
grab  whatever  input  is  present  in  the  read  queue  regardless  of 
shsthar  the  device  is  dona  sanding  :  full  packet  or  not.*/ 
tty.c.cflag  a  HUPCL  I  CSS  I  <3.0C1L  I  CREAD  I  vpvirt.speed; 
tty.c.lflog  “0; 
tty.c.iflag  *  lOIBRI; 
tty.c.oflag  »  0; 
tty.c.cc[VHII]  -  0; 
tty.c.ccCVTIHE]  »  0; 

} 

else 

{ 

/*  This  sets  up  the  port  for  "canonical"  input.  The  read  queue  sill  not 
Bake  a  packet  available  to  the  read  routine  until  a  <cr><lf>  is 
received.  */ 

fprintf (stdarr, "Port .Boda  is  canonicalVn") ; 
tty.c.cflag*  EUPCX  I  CSS  I  CREID  I  *port. spaed  I  CLOCiL; 
tty.c.lflag  •  ISIO  I  ICAIOI; 

tty.c.iflag  -  IGIBRK; 

> 

/•  Bos  set  up  the  port  using  the  TCSETA  call  to  ioctl.  This  resets  the 
port  and  flashes  the  output  queue  •/ 
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ioctKport.FD,  TCSETAF,  (chai  «)  »tty); 

} 

•FD  «  port.FD; 

} 

— *****************************t*********************«************************* 

—  CLASS  ;  Port 

—  PURPOSE:  This  is  an  abstract  class  used  to  impiament  RS232  ports. 

--  FILEIAHE;  port. a 

—  HETHODS:  create  —  Constmctor,  common.Tiee.of ,  port.sieu.of .part.of , 

coBBon.rieB.of ,  port.siee.of . 

—  Read,  Hrite.To.Port ,  Open.Port,  Cloaa_Port,  Flus^_()oene 
are  all  sirtnal  functions  to  he  isiplefflented  by  loser  level 

—  classes . 

—  Oet.Port.Open  -  returns  the  only  attribnte  of  Port. 

—  DESIQI  DECISIOfS:  This  standardizes  the  protocol  of  the  Port  classes. 


sith  conanon.object ; 
sith  oncheckad.consersion; 
package  Port  is 

type  port.nmsbers  is  (port.one,  port.tso,  port.three,  port.fonr, 
port.fise,  port. six,  port.sesen,  port.eight); 
type  port.speed.spec  is  (bl9200,  b9C00,  bl200,  b300) ; 
type  port_inpat.aiode  is  (ras,  canonical); 
type  port.coma.type  is  (terminal,  modem,  flou..control) ; 
type  variable : 

type  state  is  access  variable; 
type  variable  is  record 

port. open  ;  boolean;  —flags  if  port  is  open 
off 8pring.no  :  natural  ;«  0; 
heir  :  common.object. object; 
end  record; 

- — This  function  is  an  instantiation  of  the  generic 
• — function  UICHECKED.COIVERSIOI  converting  the  type  Common.ObJect 
—to  access  values  of  type, 
function  comon.vies.of  is  nes 

unchecked.conversion  (source  ■>  port. state, 

target  •>  common.object. object); 

—This  function  is  an  instantiation  of  the  generic 
---function  UICHECKED.COIVERSIOI  converting  access  values  of  type 
—port. state  to  the  type  Cotmaon. Object . 
function  port.vies.of  is  nes 

unchecked.conversion  (source  O  common. abject. object, 
target  »  port. state); 

- It  performs  the  Inverse  UICHECKED.COIVERSIOI  to  the  CREATE 

—function.  Given  a  reference  of  type  Common.object  .Object, 

- it  returns  a  reference  of  the  access  type  defined  its  package. 

function  part. of  (OB  :  in  common.object. object)  return  stats; 

—The  purpose  of  this  function  is  linking  the  tso  nodes  together 
—transparently.  It  enable  the  heir  field  of  the  first  node  to 
—point  to  a  record  of  the  other  node,  and  make  them  reference 

-  of  type  Common.object. Object. 

function  Create  (offspring.no  :  in  natural  ;•  0) 
return  common.object . object ; 

—This  function  returns  the  only  attribnte  of  Port, 
function  Get.Port.Open  (OB  :  in  common.object .object) 
return  boolean; 
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function  Open.Port  (OB  ;  in  conraon.object .object)  return  boolean; 
function  Cloae.Port  (OB  :  in  conmon.object .object)  return  boolean; 


procedure  Flush.Queue  (OB  ;  in  conmon.object .object)  ; 

procedure  Delete_UiuBanaged_RS232_Port  (OB  :  in  conon.object  .object)  ; 


procedure  Read_Frogi_Port  (OB 

Buffer 

nun.chara_to_read 

count 


in  coBBon.object. object; 
in  out  string; 
in  integer; 

out  integer) ; 


procedure  Write_To.Port(OB 

buffer 

nu>_chara_to_srite 


in  caanaon.object. object; 
in  out  character; 
in  integer) ; 


UIDER.FLOV  ;  exception; 
end  port; 


package  body  Port  is 
package  self  is 

function  Open.Port  (OB  :  in  conmon.object. object) 
return  boolean; 

function  Closo.Port  (OB  :  in  conmon.object .object) 
return  boolean; 

procedure  Flu.ih.()uaue  (OB  ;  in  conmon.object  .object) ; 

procedure  Delete.Unmai<a3ed.RS232.Port  (OB  :  in  conmon.object  .object) ; 

procedure  Read.From.Port(CB  :  in  comntn.object. object; 

Buffer  :  in  out  string; 

n.ui.chsrs.to.read  :  in  integer; 

count  :  out  integer) ; 

procedure  Vrite_To.Port(OB  ;  in  conmon.object. object; 

buffer  ;  in  out  character; 

num.chars.to.srita  :  in  integer);  end  self 

package  body  self  is 

function  Open.Port  (OB  ;  in  conon. object  .object) 
return  boolean  is 

begin 

if  port. part .of (OB)  >  null  then 
raise  UIDER.FLOV; 

else 

return  false; 
end  if; 
end; 

function  Close.Port  (OB  :  in  coamon.object .object) 
return  boolean  is 

begin 

if  port .part.of(aB)  >  null  then 
raise  UIDER.FLOV; 

else 

return  false; 
end  if; 
end; 

procedure  Flush.Queue  (OB  ;  in  coamon.object .object)  is 
begin 

raise  UIDER.FLOV; 
end; 

procedure  Delete.l'nnanaged.RS232.Port  (OB  ;  in  coHon.object .object)  is 
begin 

raise  UIDER.FLOV; 
end; 
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procediir€  Read.From.P 

fer 

ziiun.char8_to_r«ad 

count 

begin 

raise  UIDER.FLQV; 
end; 

procedoxe  Vrite.To_Port(03 

buffer 

nun.  chars,  to.srite 


in  conmon.object .object; 
in  out  string; 
in  integer; 

out  integer)  is 


in  cosaaon.object .object; 
in  out  character; 
in  integer)  is 


begin 

raise  UIDER.FLOV; 
end; 
end  self ; 

function  part.of  (OB  :  in  conmon.object  .object)  return  state  is 
begin 

return  port. vieu.of (OB. heir) ; 
end; 

function  create  (offspring.no  :  in  natural  0) 
return  conmon.object . object  is 
com.obj  :  coicmon. object. object; 
port.obj  :  state; 
begin 

port.obj  :•  nee  variable; 
port.obj.offapring.no  off spring.no ; 

port.obj .heir  :•  null; 
com.obj  :■  conmon.object .create(l) ; 
com.obj.heir  conmon.viev. of (port.obj) ; 
return  com.obj ; 


end; 

function  Get. Port. Open  (OB  :  in  common.object .objec*) 
return  boolean  is 


tem.OB  :  state; 
begin 

tem.OB  nee  variable; 
tem.OB  part.of <0B); 
return  tem.CB.port.open; 
end  Qet..Port.Open; 

function  Ops,n.Port  (OB  :  in  common.object  .object) 
return  boolean  is  separate; 
function  Close.Port  (OB  :  in  common.object .object) 
return  boolean  is  aeparate; 
procedure  Flush.Queue  (OB  :  in  common.object .object) 
is  separate; 

procedure  Delete  .Unmanaged.RS232.Port  (OB  :  in  common.object .object) 

is  separate; 


procedure  Read.From.Port(OB 

Buffer 

num. chars. to. re ad 
count 

is  separate; 

procedure  Vrite.To.Port(OB 

buffer 

aum.chars.to.vrite 
ie  separate; 

end  Port; 


in  COBBOB. object. object ; 
in  out  string; 
in  integer; 
out  integer) 

in  common.object. object; 
in  out  character; 
in  integer) 


e*e  File  neme  :  Separate.Bead.From.Port,aeeee*eee**eeeee*eee**eeeee 
eee  Purpose  :  This  Read_From_Port  method  vas  separate  fron  main  « 
***  Port  package  to  implement  rethod  selection  sell  ate 
eee  run-time.  This  reduces  recompilation,  eteeeeeeeeeee 


vith  Unmanaged.RS232.Port ; 
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< 


■•parat*  (Port) 
proca4aro  Koad.rroa.Port 


(OK  t  la  coaBMB.objoct.ebJocti 

•affar  :  la  oat  atrlof; 

aaaucbara.ta.road  :  ia  latogori 

coaat  :  oat  latagor)  la 

bogia 


If  port.pBrt.of(CK:  tbaa 

aolf .Kaad.Froa.  «v-ab,Oaffor,aaa.cbata.ta.raad, coaat); 

alaa 

Oaaaaagod.KS'i.  'art  .Koad.Proa.Port 

(01 , Kal f or , Baa.cbora.to.road .coaat ) ; 

oad  If; 
oad; 


••  CLKSS:  UBBoaagod  KS23]  Port 

PUKPOSK:  Tbla  alloaa  tka  aaar  to  accoaa  aa  KS333  port.  Tbla  dooa  ao 
**  cbocklag  of  carroat  port  aaogo. 

—  IIKCKITKD  FKOII:  Port 

--  FIUIKHI:  aKS333port.a.a 

—  RKnODS:  Croato.of,  part.of,  Coaaoa.TloO.of .  UaBaaagod.KS333.Port.aloa, 

Koad.ProaLPort 

—  trlto.To.Port 

"  Opoa.Part 

••  Cloao.Part 

••  Flaah.Qaoao  •  cloara  tha  ^aaaa  far  tha  part 

—  DCS14I  DCCtSlOKS;  Dlffaraat  tppaa  of  porta  aara  craatad  ta  glaa  tka  aaar 
••  a  raaga  of  dlffaraat  tppaa  of  porta  aad  aaa  tkaa  all  la  tka  aaao  tap. 


altkport;  aaa  part; 
alth  apataa; 

altk  laagaaga;  aaa  laagaaga; 

altk  ttf; 

alth  oa.fllaa; 

alth  caaaaa.objact ; 

alth  aachackad.coaaoralaa; 

packago  BaBaaagad.K1333.Port  la 

tppa  aarlabla; 

tppa  atata  la  accoaa  aarlabla; 
tppa  aarlabla  la  racord 

port.FP  :  aa.fllaa.flla.daacrlptar;  •*  part  flla  daacrlpter  aaabar 

part.tppa  :  part .part .coaa. tppa;  ••  taralaal,  aodaa  or  floa  control 

part.aaabar  :  part .part .anabara;  *■  part  aaabar  af  doalca  (alnna  1) 

ttp.tppa  :  ttp.tarala;  ••  part  aattlaga 

partuaoda  :  part  .part. lapat.Boda;  **  part  aada 

part.apaad  :  latagar; 
affaprlBg.Ba  :  aataral  :■  0; 
hair  :  ctaBaB.abJact .abjact; 

and  racard; 

*"Thla  faactlaa  la  aa  laataatlatloa  af  tha  gaaarlc 
***fBactlaa  OBCItCttS.COITKKSIOl  coaaartlag  tka  tppa  Coaaaa.Objact 
*"ta  accaaa  aalaaa  af  tppa. 
faactlaa  caaaoa.alaa.af  la  aaa 

aachackad.caaaaralaa  (aaarca  ■>  atata. 

targat  ■>  coaaoa.abjact. abjact); 
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* — Tki«  foscxlea  la  an  Inataatiatioa  of  tho  ganoiir 
.—function  UfCBECIED.COfVERSIOl  conaartlng  aecaaa  oalnaa  of  typo 
— port.atato  to  tho  typo  Coaaon.ObJoct . 
function  UaBanagod.RS232_Port.Tlon. of  la  nan 

nnchockad.conToralon  (aonrco  ■>  coMon.obJoct.objact, 
targot  ■>  atato); 


—It  porforaa  tho  Innarao  UICHECIED.COIVEXSIOI  to  tho  CREATE 
-'-function.  2lTon  a  roforonca  of  typo  Coaaion.Objact .Objoct, 
—It  rotutna  a  roforonca  of  tho  accoaa  typo  doflnod  Ita  packaga. 
function  part.of  (OB  :  In  coaioa.objoct. objoct)  ratnrn  atato; 


—Tho  purpoaa  of  thla  function  la  linking  tho  tno  nodoa  togotbt 
— tranaparontly.  It  ancbla  tho  hair  fluid  of  tho  firat  nodo  to 
—point  to  a  racord  of  tho  othor  nodo,  and  aaka  thoa  roforonca 
—  of  typo  Coaaion.Objact. Objoct. 
function  croata.of  ( 

port .BUB  ;  in  port .port. nuabora; 
apood  :  In  port .port. apoad.apoc; 

BOda  :  In  port .port. Inpnt.Bodo; 

port.c.typo  :  In  port .port.caaa.typo; 

affaprlng.no  :  In  natural  :■  0) 

raturn  conaon.objoct. objoct; 

—Tho  purpoaa  of  function  la  to  opon  tho  ayatoa  porta. 

—It  parforaa  roaotlng  tho  narlabloa  la  tho  taralo  atructura  to  roproaont 
—tho  nay  la  nhlch  yon  nlah  tho  port  to  bohano  throngh  Coo  routlno  callod 
— ' ‘e.port.opon" . 

fanetloB  Opon.Port  (OB  :  li  conaon.objoct  .objoct)  rotum  booloaa; 
procalura  c.port.opoa(port.FD.nnB  :  In  ayataa.addroaa; 

ttyport  ;  In  ayataa.addroaa; 
port.apood  ;  la  ayataa.addroaa; 

P.BOda  :  la  ayataa.addroaa); 


—Tho  purpoaa  of  function  la  to  cloaa  tho  ayatoa  porta, 
function  Cloaa.Port  (OB  :  la  conaon.objoct  .objoct)  rotum  boolean ; 

—Tho  purpoaa  of  function  la  clear  the  queue  for  tho  port, 
precadnra  Pluah.Quouo  (OB  :  la  conaon.objoct. object)  ; 

—Tho  purpoaa  of  function  la  dolota  the  object. 

procedure  &9leto.UnBaBagod.tS232.Port  (OB  :  In  coiaMn.object .object)  ; 


—Tho  purpeaa  of  function  la  road  a  data  anallablo  on  the  ayatoa  port, 
procedure  Boad.Proa.Port(OB  :  lu  coBaoB_ebjoct. objoct; 

Buffar  :  la  out  atrlng; 

aua.chara.to.raad  :  la  iatagor; 
count  :  out  intogor) ; 


—The  purpoaa  of  function  la  aet  a  apeciflc 
pracodura  Wrlta.Te.Port(OB 

buffer 

aaB.chata.te.nrlti  ; 


pert  Bode. 

in  coaBOB_ebjoct. objoct; 
in  oat  character; 
la  intogor) ; 


pragaa  IBTERFRCK  C,  e.port.opon); 

pragaa  IBTERFlCni.lRXEl  e.port.opon,  C.SUBP.PREFIX  B  ''c.pert.epen” ) ; 


and  DBBaaagad.BS232.Port; 


with  tait.io;  nao  tait.le; 

nltk  tty; 
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■1th  oa.filta;  uaa  QS.fllaa; 

■1th  analgnad.typaa;  uat  nnslgnad.tjpaa; 

■1th  loctl; 

■1th  Unix; 

packag*  body  Uiuianagtd_ItS233_Port  la 

packaga  IIT.IO  la  »■■  lotagar.ladntagax); 
naa  IIT.IO; 

packaga  port.FD.IO  la  naa  lntagar.lo(oa.lllaa.flla_dascTlptor) ; 
naa  port.FD.IO; 

packaga  port.nnnbara.lo  la  naa  annaaratloa.lolport.port.nnabara); 
naa  port.naBbara.lo; 

packaga  port.coBai.typa.lo  la  naa  annnaratloB.lo(port.poTt.coaH.typa); 
naa  port. eons. typa.lo; 

packaga  port.lnpntjaoda.lo  la  naa  annBaratlon.la(port.port.lapnt.Boda); 
naa  port. lapnt. soda. lo; 


—  BETHOD:  Part. of 

—  PURPOSE;  Olaan  OB,  It  ratnrna  a  rafaranca  of  tha  accaaa  typa  daflnad 

—  Ita  packaga 


fnnctlon  part.of  (OB  :  In  conaon.objact .objact)  ratnrn  atata  la 
bag  la 

ratnrn  Uiuianagad.RS232.Part.alaa.of (port .part.of (OB) .hair) ; 
and; 


—  RETBOD:  Craata.of 

—  PURPOSE;  Thin  nata  np  tha  port  according  to  tha  naar'a  apaclflcatlona. 


fnnctlon  craata.of  ( 

port.nna  ;  In  port .port.nnabara; 
apaad  ;  la  port .port. apaad.apac; 

■oda  :  la  port. port. Inpntjnoda; 

portie.typa  ;  In  port .port. coaB.typa; 

offaprlag.ao  ;  In  natnral  ;■  0) 
ratnm  coaaon.objact  .objact  la 
coa_abjnet  ;  eonBoa.objaet .objact; 
ra332port  ;  Uuianagad.RS232.Port. atata; 
bagln 

rn332port  ;■  naa  Uuunagad.RS232.Port.Tar labia; 
ra232port.offaprlng.no  :■  of faprlng.no ; 
ra332port.holr  :■  nnll; 
ra233port.port.Boda  ;■  soda; 
ra333port. port. typa  :■  port.c.typa; 

~~  aat  port  .nnabar  to  ona  laaa  than  actual  In  ordar  to  aaka  array  accaa:; 
"  aaaiar.  Sat  port  typa  for  hardaara  handahaklng  that  anat  ba  dona 
ra333port.port.nnBbcr  :■  port.nna; 

"  Load  th^  apaad  Tarlabla  according  to  tha  naar’a  raqnaat  and  nalng 
"  tha  ayabollc  conatanta  found  In  taralo.h.  Ba  adalaad  that  tha 

dip  aaltchan  on  tha  bottoa  of  tha  daalca  anat  ba  aat  for  tha  apaad  yon 
*-  aant  aln'ca  thla  can’t  ba  aat  by  tha  coapntar.  Thla  aaraly  aata  hoa  faat 
—  tha  RS333  PORT  alll  racalaa  atnff. 
caaa  apaad I  la 
■han  port^bl9200  ■> 

ra33iport .port.apaad  ;■  lntagar(tty.B19200); 

■han  port.b9e00  ■> 

ra333]^rt  .port .apaad  ;■  lntagar(tty .B9600) ; 

■han  port.bl300  ■> 

raSSSplort .port.apaad  ;■  lntagar(tty.B1300); 

■han  port.bSOO  ■> 

ra333pOrt.port.apaad  ;■  lntagar(tty .B300); 

■nd  caaa;  > 

coB.objact  :■  port.craata(l) ; 

port .part.of (cca.obJact) .hair  ;■  coaBon.Tlaa.of(ra333port); 
port. part.of (coa.objact).port.opan  ;■  FALSE; 
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ratnrn  coa.obj«ct; 
•nd  Craatc.of ; 


"  HETBOD;  Open. Port 

—  PUKPOSE:  Qivan  th*  atttings  craatad  ahan  tha  objact  aaa  instantiatad,  thla 

—  doas  tha  UlIX  calls  to  sat  up  and  opan  tha  RS232  port . 


function  Opan.Port  (OB  ;  in  coaaon. objact .objact)  xatnrn  boolaan  Is 
port.FD.nuai  :  intagar; 
ttjport  :  stringCl . .11) ; 

P_Boda  ;  intagar: 

T  ;  boolaan  :•  Tma; 

bagin  —Bain  opan.port 
if  not  Port .gat.Port.OpanCQB)  than 
ttjportCl . .8)  :■  "/daT/tty"; 

if  part.of (OB) .port.typa  ■  port .tarminal  than  —  port  typa  is  tarainal 
ttyport(S)  :«  ’d*; 
taxt.io.put.linaC'ttyportO)  >  d"); 
alsif  part.of (OB) .port.typa  •  port.Bodaa  than  —  port  typa  is  BodoB 
ttyportO)  :■  >B>; 
taxt.io.pnt.lina(“ttyport(9)  •  b"); 

alsif  part.of (OB) .port.typa  •  floa.control  than  —  port  typa  is  flos  control 
ttyportO)  :«  'f’; 
taxt.io.put.linaC'ttyportO)  •  f"); 
and  if; 

ttyport(lO)  ;•  charactar’TaKport.port.nuBbars’pos 

(part.of (OB) .port.nuBbar)  ala  charactar ’pos( ’0’)) ; 
ttyport(ll)  :•  ascii. nul; 

—Call  tha  C  prograa  that  calls  tha  systaB  calls; 

P.Boda  :a  port. port. lnpnt.Boda’pos(part.of (OB) .port.Boda); 
e.port.opaB(port.FD.nna’addrass,ttyport ’addrass, 

part.of (OB) .port.apaad’addrass,P.Boda'addrass) ; 
part. of (OB) .port. FD  ;■ 

as.filas.fila.dascriptor’(os.filaa.fila.dascriptor(port.FD.nua)) ; 
if  port.FD.nnB  /■  -1  than 

port .part.of (OB) .port.opan  :>  TRUE; 
and  if; 
and  if ; 

ratum  port.aat.Port.Opan(aB); 
and  Opan.port; 


—  METHOD ;  (n.osa.Port 

—  PURPOSE:  Cloaas  tha  port  (if  it  uas  open)  and  ralaasas  tha  UIIZ  fd. 


function  Cloaa.Port  (OB  :  in  conBon. objact .object)  return  boolaan  is 
bagin 

I  if  port .6at.Port.0pan(0B)  than 
!  port .part.of (OB) .port.opan  :>  FALSE; 

os.filas.cloaa(part.of(OB) .port.FD); 
i  and  if ; 

ratum  port  .Qat.Port.Opan(OB) ; 
and  Cloaa.Port; 


-4  HETBOD:  Flash.Quana 

PURPOSE:  Clear  tha  queue 


in  coBBon.objact .object)  is 


prbcadura  Flush.Quaua  (OB 
trasult  :  intagar  :■  0; 
agin 

if  ioctl.loctl(part.of(OB) .port.FD, 

I  iectl.TCFLSH, result ’addrass)  •  -1 

taxt.lo.pat.lina("fail  to  flush  tha  buffer”); 
and  if; 

and  Flush.Quaua; 


then 
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HETEOD:  D«l«t«.Uiuumag«<l.RS232.Port 
—  PURPOSE:  objact 


procadur*  D«l«t*_UiiBanag«d.RS232_Port  (OB  :  In  coBBon.objact  .objact)  is 
closa.atatos  :  boolaan; 
tagin 

closa.statns  :■  Closa_PoTt(OB) j 
and  Dalata.UnBanagad_RS232_Part; 


—  HETBOD:  Raad_FroB.Port 
--  PURPOSE: 


procadnra  Raad_FroB.Port(OB  :  In 

Bnffar  :  In  oat 

naB_chars.to_raad  :  in 

count  :  ont 

T  :  ttringd .  .nuB.chara.to.raad  a  1); 

Ian  :  intagar  :•  T’last; 
bagin 

T(l..lan-1)  :•  Bnffar: 

T(lan)  :■  ascii. nnl: 

count  :■  nniz.Taad(part_of(QB) .port.FD, 

T’addrass,  nnB_chars.to_raad) ; 
bnffar  :■  T<1. .Ian  -  1); 
and  Raad_FroB.Port : 


coBBon.objact . objact ; 

string: 

intagar: 

intagar)  is 


—  HETBOD :  procadnra  Vrita.To.Port 

—  PURPOSE: 


procadnra  Vrita.To.Port (OB  :  in  cotaion.obJact .objact: 

bnffar  :  in  out  cbaractar; 

nna.chars.to.srita  :  in  intagar)  is 

bagin 

aa.filas.srita(part.of(OB) .port.FD, 

bnffar ’addrass,  naB.cbars.to.srita) : 

and  Vrita.To.Port; 
and  UnUBagad_RS232.Port ; 
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